Parcel: Bug-ish: compiling of linked modules

[tj]

🐛 bug report

I think this is a bug, you used to be able to yarn link / npm link another module which had babel / JSX etc and it would magically just work (which is amazing haha), however with bundler 1.6.2 I now get:

Server running at http://localhost:3000 
🚨  /Users/tj/dev/src/github.com/tj/cloudwatch/node_modules/@apex/ui/App.js:10:9: Unexpected token (10:9)
   8 | 
   9 | export default function({ children }) {
> 10 |   return <div class="App">

🎛 Configuration (.babelrc, package.json, cli command)

My config for the main project and the linked one are both:

{
  "dependencies": {
    "aws-sdk": "^2.181.0",
    "moment": "^2.20.1",
    "react": "^16.2.0",
    "react-dom": "^16.2.0",
    "react-virtualized": "^9.18.0",
    "sleep-promise": "^2.0.0"
  },
  "devDependencies": {
    "babel-plugin-react-html-attrs": "^2.1.0",
    "babel-plugin-react-require": "^3.0.0",
    "babel-plugin-transform-class-properties": "^6.24.1",
    "babel-plugin-transform-object-rest-spread": "^6.26.0",
    "babel-preset-env": "^1.6.1",
    "babel-preset-react": "^6.24.1",
    "parcel-bundler": "^1.6.2"
  },
  "babel": {
    "plugins": [
      "transform-class-properties",
      "transform-object-rest-spread",
      "react-require",
      "react-html-attrs"
    ]
  }
}

🤔 Expected Behavior

Linked would get compiled as configured as well.

😯 Current Behavior

Above :D

💁 Possible Solution

Not sure if the old behaviour was intended or not, or if it's recommended to pre-build the linked package — if so that's not a huge problem!

🔦 Context

Local development.

🌍 Your Environment

| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 1.6.2
| Node | 8.9.4
| npm/Yarn | Yarn 1.1.0, NPM 5.6.0
| Operating System | OSX 10.12.6

Donated :D thanks for the fantastic project

[devongovett]

Yeah, this was a change in behavior in v1.6.0. Unfortunately, too many packages on npm publish .babelrc files even though they are already compiled which was breaking builds. See #13.

I have this exact problem as well, so I'm hoping to solve it by somehow telling parcel that a module is actually source code rather than a precompiled package. In #13 we are discussing adding a source field to package.json for that potentially. Feel free to weigh in!

[tj]

Awesome thanks!

[tj]

Hmm yea extra tricky with this scenario since reaching into the pkg modules with @apex/ui/Foo instead of just @apex/ui doesn't work with pointing main to a build.

[hzoo]

https://github.com/babel/babel/pull/7358 should help with this, basically will ignore .babelrc from node_modules by default and use the root one.

[tj]

Ended up reverting to pre-1.6 for now, but I thinkkkk it should be pretty safe to apply the old behaviour to symlink'd packages, tough call though.

[andreyvital]

Yo @devongovett—any progress on this one? 🤔

I'm facing the exact same problem, we're using Yarn workspaces to build and share some of our UI infrastructure pieces and we can't import any package that needs to be compiled in the root workspace level :(

[devongovett]

Made #1101 which adds support for a source field to enable compilation of symlinked modules. Would be curious to hear your feedback!

[emilsjolander]

I'm having the same issue in https://github.com/parcel-bundler/parcel/issues/1571 but with --target=electron instead of --target=browser. @devongovett does your fix apply for for targets or just browser target?

[rafaelcorreiapoli]

Any updates on this? I'm facing the same problem targeting electron and using yarn workspaces

[DalderupMaurice]

Im facing another issue, using yarn/npm link, parcel tries to resolve the dependency by executing yarn install and it fails to download the package, executes yarn install again, fails again... resulting in an infinite loop