Skip to content

next@b2fd8db8 throws if monorepo with nwb modules #4249

Closed

Description

@bebbi

Is this a bug report?

yes.

I'm using the next branch with a monorepo including a cra app and a few nwb modules and am getting the following error:

Failed to compile.

../nwb-lib/es/index.js
/path/proj/packages/nwb-lib/es/index.js
  3:1  error  Import in body of module; reorder to top  import/first

See also insin/nwb#450
@Gaeron suggested to repost here.

Did you try recovering your dependencies?

yes

Which terms did you search for in User Guide?

n.a. I think

Environment

  1. node -v: 8.9.1
  2. npm -v: 5.7.1
  3. yarn --version (if you use Yarn): 1.5.1
  4. npm ls react-scripts (if you haven’t ejected):

Then, specify:

  1. Operating system: macos 10.13.4
  2. Browser and version (if relevant): n.a.

Steps to Reproduce

  1. Create a cra monorepo project
  2. with one package being a nwb component with an es build (web-module in my case if it matters)
  3. build the component and run the app

Expected Behavior

Should just run fine.

Actual Behavior

yarn start doesn't serve but instead shows the above error.

Reproducible Demo

I will try if this issue is not very straightforward.

Activity

  1. gaearon commented on Apr 3, 2018

    @gaearon
    Contributor

    This sounds like the fix would be to wait for #4092.

  2. bebbi commented on Apr 3, 2018

    @bebbi
    ContributorAuthor

    @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.

  3. added this to the milestone on Apr 3, 2018
  4. gaearon commented on Apr 3, 2018

    @gaearon
    Contributor

    🤔

    In that case we should exclude "publishable" packages from linting.

  5. 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
  6. bebbi commented on Apr 10, 2018

    @bebbi
    ContributorAuthor

    It might be useful to add "Cannot co-exist in a monorepo with publishable packages" to the known issues in #3815?

  7. 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
  8. bradfordlemley commented on Apr 13, 2018

    @bradfordlemley
    Contributor

    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.

  9. bradfordlemley commented on Apr 13, 2018

    @bradfordlemley
    Contributor

    @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.

  10. modified the milestones: 2.0.x, 2.x on Sep 26, 2018
  11. removed this from the 2.x milestone on Nov 2, 2018
  12. stale commented on Dec 2, 2018

    @stale

    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.

  13. stale commented on Dec 8, 2018

    @stale

    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.

  14. locked and limited conversation to collaborators on Jan 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions