You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
next@b2fd8db8 throws if monorepo with nwb modules #4249
@gaearon not sure it is related, as the above nwb-lib is publishable and by definition of the referenced proposal it would still need its own build mechanism and be out of scope for source packages.
changed the title [-]next@b2fd8db8 throws "Import in body of module; reoder to top" for nwb module[/-][+]next@b2fd8db8 throws "Import in body of module; reorder to top" for nwb module[/+]on Apr 5, 2018
changed the title [-]next@b2fd8db8 throws "Import in body of module; reorder to top" for nwb module[/-][+]next@b2fd8db8 throws if monorepo with nwb modules[/+]on Apr 10, 2018
The current alpha implementation doesn't provide a mechanism to specify which packages in the monorepo should be built/linted -- if your app includes another package in the monorepo, it will be transpiled and linted. This leads to an incompatibility with nwb packages in the monorepo because the nwb-built output (es/index.js) fails to lint (because it has some functions defined at the top of the file, then imports can happen later on).
#4092 proposes a mechanism to specify which packages should be built/transpiled and their source entry points, so it will allow nwb packages to in the monorepo to be used by the app, either by not specifying them as source packages, or specifying their "source" entry point. However, it requires the source packages to be "private", which essentially prevents the app from utilizing nwb packages as source packages because there's almost no reason to use nwb unless you're going to publish your package.
@gaearon Would you be open to relaxing the "private" flag requirement if the package contains both "source" and "main" (or "browser", "module") entry points? This would allow publicly-published packages (like nwb packages) to be used as source packages, but also help ensure that any publicly-published packages conform to npm ecosystem standards.
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
Activity
gaearon commentedon Apr 3, 2018
This sounds like the fix would be to wait for #4092.
bebbi commentedon Apr 3, 2018
@gaearon not sure it is related, as the above
nwb-libis publishable and by definition of the referenced proposal it would still need its own build mechanism and be out of scope for source packages.gaearon commentedon Apr 3, 2018
🤔
In that case we should exclude "publishable" packages from linting.
[-]next@b2fd8db8 throws "Import in body of module; reoder to top" for nwb module[/-][+]next@b2fd8db8 throws "Import in body of module; reorder to top" for nwb module[/+]bebbi commentedon Apr 10, 2018
It might be useful to add "Cannot co-exist in a monorepo with publishable packages" to the known issues in #3815?
[-]next@b2fd8db8 throws "Import in body of module; reorder to top" for nwb module[/-][+]next@b2fd8db8 throws if monorepo with nwb modules[/+]bradfordlemley commentedon Apr 13, 2018
To summarize:
The current alpha implementation doesn't provide a mechanism to specify which packages in the monorepo should be built/linted -- if your app includes another package in the monorepo, it will be transpiled and linted. This leads to an incompatibility with nwb packages in the monorepo because the nwb-built output (es/index.js) fails to lint (because it has some functions defined at the top of the file, then imports can happen later on).
#4092 proposes a mechanism to specify which packages should be built/transpiled and their source entry points, so it will allow nwb packages to in the monorepo to be used by the app, either by not specifying them as source packages, or specifying their "source" entry point. However, it requires the source packages to be "private", which essentially prevents the app from utilizing nwb packages as source packages because there's almost no reason to use nwb unless you're going to publish your package.
bradfordlemley commentedon Apr 13, 2018
@gaearon Would you be open to relaxing the "private" flag requirement if the package contains both "source" and "main" (or "browser", "module") entry points? This would allow publicly-published packages (like nwb packages) to be used as source packages, but also help ensure that any publicly-published packages conform to npm ecosystem standards.
stale commentedon Dec 2, 2018
This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.
stale commentedon Dec 8, 2018
This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.