vivid-planet / comet

Comet DXP

Home Page:https://comet-dxp.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Importing from subdirectories

fraxachun opened this issue · comments

With the consolidation the importing of the former subpackages has changed. Du to naming collisions it is not possible to export everthing at root level. How should it work from now on?

Before:

import { FinalForm } from "@vivid-planet/react-admin-core";	
import { Field, FormPaper, Input } from "@vivid-planet/react-admin-form";	

1. Current Solution:

import { FinalForm, form } from "@vivid-planet/react-admin";
const { Field, FormPaper, Input } = form;

2. Export everything at root level.
Therefore we have to solve the naming collisions, e.g.:

import { FinalForm, FormField, FormPaper, FormInput } from "@vivid-planet/react-admin";	

3. We use subdirectory-imports

import { FinalForm } from "@vivid-planet/react-admin";
import {  Field, FormPaper, Input } from "@vivid-planet/react-admin/form";

This is currently not possible out of the box. If we import from "@vivid-planet/react-admin/form" the subdirectory "./form" in the "node_modules/@vivid-planet/react-admin" directory is used - which does not exist as we build into the "lib"-directory.

There are three solutions I can think of:
a. We build into the root directory. Then there is the danger of file collisions and the ./src exists in the lib. However, currently it should work and is an easy solution.
b. We write index files for every subdirectory. E.g. react-admin/form.js (and form.d.ts) which exports everything from the subdirectory. Hacky and manual solution.
c. We try to find a solution during the build process. However, I don't think that is too easy especially
when we want to keep the simple tsc compilation. Besides that there is already a standard to achieve this (https://nodejs.org/api/packages.html#packages_exports), but typescript doesn't recognize it yet (microsoft/TypeScript#33079).


Please answer with your favoured solution (1, 2, 3a, 3b, 3c).

2, though FormInput could be Input (try to keep material-ui names where possible, in this case our input only adds styles I think)

FormPaper is Ok, as it is a material-ui Paper with Form specific default styling (at least i suppose it is)

Closed as #243 has been merged.