Babel-loader: Doesn't compile a npm linked module

[acnovais]

Not sure this is a babel loader issue or a webpack issue.

I am developing two modules and one of them has a dependency on the other. So I have npm linked it.
I have the following config on webpack:

loaders: [{
      test: /\.js$/,
      loaders: ['babel'],
      exclude: /node_modules\/(?!other-module)/,
      include: __dirname
}]

This works fine if I install dependency as a local dependency but if I use npm link, babel doesn't process it.

Am I missing something? Or is there a workaround for this?

[cdaringe]

interesting, I just ran into this issue as well. however, i did unlink, make a copy, clear my node modules, and retry in the copy, with no results. unsure at this point. will continue to debug

[scriptjs]

Your config is not right. You need to include babel presets in your loader config as well as your babelrc or babelConfig in your package.json. The presets for babel loader can be added with query params or query object. Review the babel 6 docs on presets for your babel config. The preset packages must also be included your project. Currently things are working for me with [email protected] with babel presets and [email protected]

[cdaringe]

perhaps you're right. I never installed _all_ of the deps. Likely part of a major bump? Readme ref

[henit]

I have the same issue. I have a package at /path/to/project/ and a dependency that worked well when located in /path/to/project/node_modules/dependency/. However, when I npm link the dependency to a git clone located at the same place as the project (/path/to/dependency/, linked via /usr/lib/node_modules the way npm links), then the loaders complain that there is no presets installed in the package directory for dependency when I run webpack from the project directory that npm links to it.

Webpack loader config in /path/to/project:

{
    test: /\.jsx?$/,
    loader: "babel-loader",
    query: {
        presets: ["es2015", "react"]
    }
}

Output from running webpack:

ERROR in ../dependency/index.js
Module build failed: Error: Couldn't find preset "es2015" relative to directory "/path/to/dependency"

How can I make babel-loader use the presets installed in the project the same way it did when the dependency where located inside the project directory instead of looking for it in the linked project directory?

[scriptjs]

@henit Try putting the presets in your package.json instead with a babel property:

  "babel": {
    "presets": [
      "es2015",
      "react"
    ]
  },

[henit]

@scriptjs Gave the same webpack error as in my post above

Having the presets in neither the loader config or directly in the webpack config makes it complain about the syntax (since the file it is trying to include is in ES6). Once I include the presets in one of the two places, the syntax error is replaced by complaining that it does not find the preset modules. Whatever I do, I cannot get the loader to use the presets from the current project modules when importing files from a dependency that is located outside of the root of the package (since I have put the npm linked module in the directory above as described earlier).

I tried adding the resolve.fallback with the parent dir (where the linked dependency is located), did not help.

[scriptjs]

@henrit Perhaps there is something not sane in your babel dependencies impacting your project but you will need to investigate this. I am faced with something just about as strange. This is having an impact on a react native app project in a monorepo. If I remove the project out of the monorepo it compiles and runs. Within the monorepo it compiles but will not run due to an exception being thrown in react native since there is something global leaking into it from babel – from where is the question – and it is bugging the hell out of me. I too take advantage of npm link in this work.

There are a lot of moving parts atm. React, babel, npm are all moving simultaneously at a significant speed which only makes getting to the bottom of these things more difficult.

[Swaagie]

Seeing the same issue, building failed with an npm link module, after removing the link and manually copying over the locally developed module it worked fine. There is something odd with symlinks going on. Webpack config is as follow. Working with [email protected] and [email protected].

'use strict';

const path = require('path');
const ucfirst = require('ucfirst');
const component = path.basename(process.env.COMPONENT);

module.exports = {
  entry: path.join(__dirname, component, 'index.jsx'),
  output: {
    filename: path.join(__dirname, component, 'dist', 'index.js'),
    library: 'UX' + ucfirst(component),
    libraryTarget: 'umd'
  },
  externals: {
    'prismjs': 'Prism',
    'react': 'React',
    'react-dom': 'ReactDOM'
  },
  module: {
    loaders: [{
      test: /\.jsx?$/,
      loader: 'babel-loader?presets[]=react,presets[]=es2015'
    }, {
      test: /\-example\.jsx?$/,
      loader: 'raw-loader'
    }]
  }
};

[Swaagie]

I'm pretty sure I've got those modules installed and it's not about the presets, babel-loader simply fails with symlinks

[skipjack]

Yea I agree with @Swaagie. The babel-loader fails to find it's preset modules when the module isn't under the project root containing the node_modules (even when resolveLoader.root is set). Similar to #166

[nirazul]

I can confirm that this has something to do with the location of the presets package.
My setup consists of two node_modules folders. One for a node-server and one for the frontend-build, which relies partially on webpack and webpack-stream.

<project-root>
    /node_modules
    /frontend
        /node_modules

I've first tried to use es2015 presets install dependency in the nested frontend folder. I've ended up getting the same error message as some others here:

ModuleBuildError: Module build failed: Error: Couldn't find preset "es2015" relative to directory "path/to/jsmainfile"

When installing it in the node_modules folder of the project root, it magically works. This made no sense to me, as babel-core as well as babel-loader and webpack are not installed within this folder.

So there must be something wrong with either the webpack option resolveLoader.root or babel-loader loading mechanism (or both).

[mqklin]

+++, related stackoverflow answer: http://stackoverflow.com/questions/34574403/how-to-set-resolve-for-babel-loader-presets/

[barroudjo]

Thanks @mqklin, this works, but unfortunately when you use multiple loaders you can't use a query object. Here is the workaround in this case:

var queryObject = {presets: [require.resolve('babel-preset-es2015')]};
var query = require('querystring').stringify(queryObject);
config.loaders = [{
    test: /\.js$/,
    loaders: ['ng-annotate', 'babel?' + query]
}];

[graup]

I have the same setup as @Nirazul. Using require.resolve('babel-preset-es2015') instead of 'es2015' resolves this issue for me.

Additionally I set resolve.modulesDirectories: [path.resolve('./node_modules')] so modules in other directories can find modules installed in the main project.

[barroudjo]

An update on this issue: while this workaround works for most babel presets, it doesn't work for babel-transform-runtime, i.e. setting up the loader with:

query: {
    presets: [require.resolve('babel-preset-es2015')],
    plugins: [require.resolve('babel-plugin-transform-runtime')]
}

doesn't work. Has anyone found a workaround for symlinks and babel-transform-runtime ?

[jbcpollak]

same problem for me, this workaround seemed to help:

The query-stringify solution seems to have helped for me.

[ChrisRus]

Chiming in on this thread as I've got a variant scenario (I think). I've developing a CLI tool that functions like a black box site generator. My intent is that the tool be installed globally and executed from the command line where it locates a containing package.json relative to cwd() that it parses to retrieve some options. Subsequently, the contents of the _target_ project (i.e. the dir structure rooted at the directory where package.json was found) is processed into a site, and the generated resources are written back out to the target project directory structure.

Internal to the tool, I synthesize webpack configuration objects and delegate to webpack which in turn delegates to babel-loader, babel ... and fails when resolving the es2015 and react presets as described here (for slightly different reasons than typical but same root cause I think).

Currently, webpack and babel loader are correctly resolved in the node_modules dir of my tool where they're declared as regular dependencies in the tool's package.json. This isn't a global install of anything more than a random Node.js derived CLI tool that happens to depend on webpack, babel... as an implementation detail.

So although I agree with the rationale of wanting to install babel on a per-project basis, this sharp edge with presets makes it difficult to embed in automation scripts.

For now I've modifying the dev-dependencies of the _target_ project package.json and going to force an npm install prior to the first invocation of webpack (occurs as one of many steps in the site generation process encapsulated by the tool). But I think this extra complexity is not really necessary.

This thread: https://discuss.babeljs.io/t/error-parsing-jsx-with-global-installation-babel-preset-react/59/14 on Babel discussion is fairly recent and seems related.

Anyone know how to get this sort of wholly encapsulated embedding to work elegantly? Thanks.

[tlrobinson]

This is happening to me as as well. @barroudjo's suggested workaround seems to work in my case:

var BABEL_CONFIG = {
    cacheDirectory: true,
    presets: [
        "es2015",
        "stage-0",
        "react"
    ].map(function(name) { return require.resolve("babel-preset-"+name) }),
    plugins: [
        "transform-decorators-legacy"
    ].map(function(name) { return require.resolve("babel-plugin-"+name) })
};

[dnutels]

@tlrobinson

I don't think it does. At least in my case this solution caused the presets to be packaged with the source code.

Have you checked yours?

P.S.

Actually, I don't know if that's what caused that... but when doing either:

1. resolve.alias for a specific module (outside of the "normal" tree)
2. above solution with presets

resulting bundle includes stuff like:

/* WEBPACK VAR INJECTION */(function(process) {/**
     * Copyright (c) 2013-present, Facebook, Inc.
     * All rights reserved.
     *
     * This source code is licensed under the BSD-style license found in the
     * LICENSE file in the root directory of this source tree. An additional grant
     * of patent rights can be found in the PATENTS file in the same directory.
     *
     */

    'use strict';

    /**
     * Use invariant() to assert state which your program assumes to be true.
     *
     * Provide sprintf-style format (only %s is supported) and arguments
     * to provide information about what broke and what you were
     * expecting.
     *
     * The invariant message will be stripped in production, but the invariant
     * will remain to ensure logic does not differ in production.
     */

    function invariant(condition, format, a, b, c, d, e, f) {
      if (process.env.NODE_ENV !== 'production') {
        if (format === undefined) {
          throw new Error('invariant requires an error message argument');
        }
      }

[skipjack]

I'm a big fan of @seantimm's solution in #179:

const babelSettings = {
  extends: path.join(__dirname, '/.babelrc')
}

...

loader: 'babel?' + JSON.stringify(babelSettings)

Easier than all those require.resolves and allows you to decouple your settings into the .babelrc again. Just thought I'd add it as another solution until @Swaagie's PR is merged in Babel...

[Swaagie]

Added tests to the PR few days ago (finally), I'll see if I can give someone a nudge.

[Jokcy]

@scriptjs I guess you are right. My project ran into this error in my mac but everything is ok on my firend's mac, and the difference is he never us react native. And my Solution is using a .babelrc file to config babel not in webpack config file. I guess babel will search for .babelrc file if project folder not contain one

[xsbchen]

It's work for me, thank you @scriptjs

[hitchcott]

I still can't get this to work. I've tried everything in this thread. Seems to be specific with npm linkd react components. ES6 appears to be working, but it's choking as soon as it gets to jsx including in a linked module.

ERROR in ../myComponent/src/test.js
Module parse failed: /Users/chris/code/myComponent/src/test.js Unexpected token (6:6)
You may need an appropriate loader to handle this file type.

    "babel-core": "^6.9.0",
    "babel-loader": "^6.2.4",
    "babel-preset-es2015": "^6.9.0",
    "babel-preset-react": "^6.5.0",
    "babel-preset-stage-2": "^6.5.0",

[Swaagie]

@hitchcott that's something else since the loaders are found, this might be the order of your loaders? Hard to tell without the config, don't hijack this issue though ;)

[rodoabad]

@hitchcott you need to use require.resolve.

[davidortizfrau]

this worked for me, Notice that I don't have a 'include' key.

{
  test: /\.js$/,
  loader: 'babel',
  exclude: /.*node_modules((?!localModule).)*$/,
  query: {
    presets: ['es2015', 'react']
  }
}

[AshCoolman]

'npm linkpackage not working for me either. A symbolic link innode_modules/` doesn't work, but copying the target of the symbolic link (the package) does work.

Are the other people getting it to work actually using npm link (with symbolic links)? Because if not, then I'm going echo the other people here and guess its symbolic links

[octatone]

Just adding that I am running into the same issue as hitchcott https://github.com/babel/babel-loader/issues/149#issuecomment-221946176

npm linked components aren't being processed by babel and throwing up on JSX encounter

[joshunger]

Adding an include to fs.realpathSync(__dirname + '/node_modules/my-repo/lib') might also be another solution thanks to https://github.com/webpack/webpack/issues/1643#issuecomment-220484356.

[larrybotha]

@davidortizfrau's exclude solution was the only solution here that worked for me:
https://github.com/babel/babel-loader/issues/149#issuecomment-226637036

  module: {
    loaders: [
      {
        test: /\.jsx?$/,
        exclude: /.*node_modules((?!my-npm-linked-module-name).)*$/,
        loaders: ['react-hot', 'babel'],
      },
    ],
  },

I was experiencing the same JSX problem as @hitchcott:
https://github.com/babel/babel-loader/issues/149#issuecomment-221946176

[hitchcott]

To update, I was able to fix this with the config:

resolve: {
  extensions: ['', '.js', '.jsx'],
  modules: [
    path.resolve('./client'),
    'node_modules'
  ],
  loaders: [
    path.resolve('./client'),
    'node_modules'
  ],
  alias: {
    react: path.resolve('./node_modules/react'),
  },
},

[MadLittleMods]

Issue on webpack/webpack repo: https://github.com/webpack/webpack/issues/1866

[eshcherbakov]

My solution which is great works:

.pipe(babel({
    presets: [require('babel-preset-es2015')]
}))

Thanks!

[tswaters]

Ran into a similar issue as @hitchcott and wound up resolving it with the following:

before (not working)

{
  test: /\.jsx?$/,
  include: [
    path.resolve('./components'),
    path.resolve('./node_modules/common-components')
  ],
  loader: 'babel-loader',
  // query: {} - not specified, deferred to .babelrc
}

after (working)

{
  test: /\.jsx?$/,
  include: [
    path.resolve('./components'),
    fs.realpathSync('./node_modules/common-components') // <-- added realpathSync
  ],
  loader: 'babel-loader',
  // define each presets/plugins in babelrc as absolute to current working directory
  query: {
    presets: [
      'es2015',
      'stage-0',
      'react'
    ].map(dep => require.resolve(`babel-preset-${dep}`)),
    plugins: [
      'transform-runtime',
      'transform-class-properties',
      'transform-decorators-legacy'
    ].map(dep => require.resolve(`babel-plugin-${dep}`))
  }
}

It should be noted, I also have the following:

// add resolve fallback for npm link'd modules
resolve: {fallback: path.join(__dirname, 'node_modules')},
resolveLoader: {fallback: path.join(__dirname, 'node_modules')},

[sktt]

Solved it simliar to @tswaters but my test runner depends on .babelrc so I still have to use it so instead I read and parse .babelrc from my webpack config:

// webpack.config.js
const babelrc = JSON.parse(fs.readFileSync('./.babelrc'));

Then I map through preset, plugins and env.development.{presets,plugins} and env.production.{presets,plugins} to resolve the absolute path using require.resolve()

{
  "presets": [
    "babel-preset-react",
    "babel-preset-es2015",
    "babel-preset-stage-1"
  ],
  "env": {
    "development": {
      "plugins": [
        "react-hot-loader/babel"
      ]
    },
    "production": {
      "presets": [
        "babel-preset-es2015",
        "babel-preset-stage-1",
        "babel-preset-react",
        "babel-preset-react-optimize"
      ]
    }
  }
}

It's a huge problem that such a basic thing as symlinks doesn't work. It kindof discourages us to factor out our code into external modules which is we should love and strive for

[andrewfinnell]

@sktt As most of us are developing within the same filesystem, we can use hardlinks instead of soft links to achieve the same effect. The only difference here is that the soft link points to the file name and the hard link points to the file i-node. I've added hardlinks to vynvl-fs and have been successfully using it to link node modules. While you can't hard link a directory, it doesn't matter because all the children files can be linked.

Hard links work quite well as long as all the files are on the same file system. Even on Windows 10.

[mgol]

While you can't hard link a directory

On macOS you can, although in a not very official way: http://brewformulas.org/HardlinkOsx

[vokeio]

@henit

I just found a method in the Babel docs. If you need a preset or plugin locally/bundled in your project like I did you can provide the plugins and presets a relative or absolute path to the node module package.

    const Babel = require('babel-core');

    const options = {
        code: true,
        presets: [
            ['./node_modules/babel-preset-es2015', {
                'modules': false,
                'loose': false,
                'spec': true
            }]
        ]
    };

    const result = Babel.transform(text, options);

Notice the preset name instead of es2015 it is a relative path ./node_modules/babel-preset-es2015.

TIP: You also might need to resolve to the absolute path in which case you can use Path.join(__dirname, './relative/path/package');

[richburdon]

I think https://www.npmjs.com/package/webpack-link solves the issue.

[acailly]

I had the same issue as @hitchcott with an app created with create-react-app and followed @tswaters suggestion, now it works.

First issue

Error in ***/shared-hybrid/src/components/common/Toast.js
Module parse failed: ***\shared-hybrid\src\components\common\Toast.js Unexpected token (15:2)
You may need an appropriate loader to handle this file type.
SyntaxError: Unexpected token (15:2)
 @ ./src/components/ObservationPage/ObservationPage.js 42:13-65

I replace in the paths:

appSrc: [resolveApp('src'), resolveApp('node_modules/shared-hybrid/src')],

by

appSrc: [resolveApp('src'), fs.realpathSync(resolveApp('node_modules/shared-hybrid/src'))],

Second issue

Nearly the same kind but not exactly

Error in ***/shared-hybrid/src/components/common/SelectServerDialog.js
Syntax error: ***/shared-hybrid/src/components/common/SelectServerDialog.js: Unexpected token (20:6)

  18 |
  19 |  const dialogActions = [
> 20 |       <FlatButton
     |       ^
  21 |         label="Ok"
  22 |         primary={true}
  23 |         keyboardFocused={true}

 @ ./src/components/HomePage/HomePage.js 54:26-91

I add the following code in the query of babel loader:

        query: {
          presets: [
            'react-app'
          ].map(dep => require.resolve(`babel-preset-${dep}`))
        }

Third issue

Error in ***/shared-hybrid/src/redux/reducers/toast.js
Module not found: 'babel' in ***\shared-hybrid\src\redux\reducers

 @ ***/shared-hybrid/src/redux/reducers/toast.js 12:15-36

Now I set:

resolve: {fallback: paths.appNodeModules}
resolveLoader: {fallback: paths.appNodeModules},

Final issue

It works! ... except I commented this section:

preLoaders: [
      {
        test: /\.(js|jsx)$/,
        loader: 'eslint',
        include: paths.appSrc,
      }
    ],

and when I suppress the comments, I get the following errors:

Error in ***/shared-hybrid/src/redux/actions/toast.js

***\shared-hybrid\src\redux\actions\toast.js
  1:1  error  Parsing error: 'import' and 'export' may appear only with 'sourceType: module'

? 1 problem (1 error, 0 warnings)

To fix that, I add in shared-hybrid/package.json:

  "eslintConfig": {
    "extends": "react-app"
  }

And it works! Hope someone will find it usefull :wink:

[DimitryDushkin]

Did someone found solution for webpack 2?

[janzenz]

@DimitryDushkin same boat I thought I was the only one having this issue. Where did you put your babel plugins? Inside the webpack config or the .babelrc file?

[DimitryDushkin]

@janzenz inside LoaderOptionsPlugin.
I've "fixed" the problem by installing all babel-related plugins in node_modules of linked module.

[mingxian]

@DimitryDushkin . Have u got some new solutions for webpack2 ?

[DimitryDushkin]

@mingxian nope =(

[theninja]

@mingxian For Webpack 2, adding this to seemed to _resolve_ (derp) the issue :

resolve: {
    symlinks: false
}

[MatteoWebDeveloper]

Ok I think I am not the only one having issue with npm link on webapck 2?!

ERROR in ./src/index.js
Module not found: Error: Can't resolve 'webpack-test-import' in '/Users/user-name/Documents/Github/test-webpack/src'
@ ./src/index.js 7:25-55
@ multi (webpack)-dev-server/client?http://localhost:8080 webpack/hot/dev-server ./index.js

[keul]

On webpack 2 the suggestion of using fs.realpathSync worked for me fixins the npm link issue, just remember to do the same for both "rules" and "alias" section.

      {
        test: /\.(js|jsx)$/,
        include: [
          './src',
          fs.realpathSync(`${npmBase}/npmlinkedmodule`)
        ],
        loaders: ['babel-loader', ]
      }

...and...

alias: {
    mymodule: fs.realpathSync(`${npmBase}/npmlinkedmodule`)
}

[larrybotha]

So round 2 for me, different project - still Webpack 1.

For anyone struggling and failing with the above settings, rm -rf node_modules may just save you hours.

Additionally, my config is now updated to explicitly pull in required transforms while using babel-preset-env, instead of babel-preset-stage-[x] and babel-preset-es2015:

webpack.conf.js:

...

module: {
  loaders: [
    {
      test: /\.js$/,
      exclude: /.*node_modules\/((?!my-symlinked-module).)*$/,
      loader: 'babel',
    },
  ]
},

...

.babelrc:

{
  "presets": ["env", "react"],
  "plugins": ["transform-es2015-destructuring", "transform-object-rest-spread"]
}

Explicit includes don't seem to want to come to the party, so exclude remains the property of choice.

[sebinsua]

@mingxian For Webpack 2, adding this to seemed to resolve (derp) the issue :

resolve: {
  symlinks: false
}

@theninja This worked for me, but I'm now wondering why it works. Do you know why it's working?

What was strange to me, was that even though I had originally made the loader.include point to the resolved location of a symlink, that didn't work. Then when I got it to just ignore the symlinks using this configuration it started to work...

I'm wondering if this bit of configuration could negatively impact anything, because if it does I'll want to be able to switch it on/off.

[vichle]

@sebinsua I have tested this a bit now and am pretty sure why it works (at least for me)!

If you have your library at /path/to/linked-package, and your project at /path/to/project.
npm linking will link /path/to/project/node_modules/linked-package -> /path/to/linked-package

Let's say you have the following exclude:

exclude: function(modulePath) {
  return /node_modules/.test(modulePath) && !/node_modules\/linked-package/.test(modulePath)
}

With symlinks: true, modulePath will be /path/to/linked-package. This will not match any of the regexp above as node_modules is not part of the path.

With symlinks: false, modulePath will be /path/to/project/node_modules/linked-package, which does match the regexp.

Hope this helps :)

[adamellsworth]

@sebinsua @vichle your solution works for me on "webpack": "^2.2.0",

Thanks for your input on this issue.

[joaoreynolds]

{symlinks: false} fixes the error, however it disrupts webpack's watch function (and therefore webpack-dev-server will not recompile when changing files in the "linked" dependency).

Anybody found another solution?

[ylg]

@joaoreynolds A few of us using it here with webpack 3.x, symlinks false in two different projects, and --watch. We see recompiles when the symlinked libraries change. But we don't use webpack-dev-server. So, not a solution, but you might try plain webpack --watch and see if you still have the problem as the root cause might be something other than watch.

[joaoreynolds]

Doesn't seem to work @ylg though I appreciate the feedback. This is the resolve part of my config:

resolve: {
    modules: [
      path.resolve(__dirname, 'dev/app'),
      path.resolve(__dirname, 'node_modules')
    ],
    extensions: ['.js', '.jsx', '.scss'],
    symlinks: false
},

[joaoreynolds]

Update, the only way I could get watching (of any kind) with npm-link to work was have symlinks: true and I had to install all babel presets and plugins in the linked dependency module - which seems weird because the linked dependency doesn't even have it's own webpack setup.

Maybe I'm the only one in thinking that if symlinks: true (default webpack behavior), then my project should look for plugins and presets in the current directory's node_modules. (just the same way it loads babel-loader which is NOT required to be installed in the linked-module)

[ylg]

@joaoreynolds We're not using resolve.modules in these two projects, for whatever that is worth. Nor do we have Webpack or Babel setup or packaged in the symlinked deps. Outer configs look roughly like:

  module: {
    loaders: [
      {
        test: /\.jsx?$/,
        exclude: /node_modules\/(?!symlinked_lib)/,
        loader: "babel-loader",
        query: {
          cacheDirectory: true,
          presets: ["env", "react"]
        }
      },
     [etc]
  },
  [etc]
  resolve: {
    alias: {
      "foo": Path.resolve(__dirname, "src/foo"),
      [etc]
    },
    extensions: [".js", ".jsx", ".scss"],
    symlinks: false
  }

But, I doubt that makes a difference. Anyway, my thought was just that --watch can work with symbolic links in node_modules and symlink === false, so I don't think the root cause for you is as straightforward as it might seem.

[andrewfinnell]

For what it's worth, symlinks properly work 100% (from my testing) with the Windows 10 Creative update. While I realize 99.9% of everyone of this thread likely uses a Linux distro, I have a feeling a bit of the "symlink" settings, and thus the difficulties with them, are due to Windows compatibility and other work arounds.

If we add a few new constraints and assumptions:

1. Given Windows 10 Developer Mode (not a poor assumption if one is developing on Windows. And all the more reason for companies to STOP using Windows 7) we now have real symlinks across the three major platforms.

2: If symlink properties are being exposed via configuration options, perhaps we can move to a more Declarative Filter? Instead of having to treat symlinks as special is can just be an attribute of the match and filter functions, along with all the other attributes a file or folder might have. We can now programmatically give back the file name and all its metadata for a Predicate to use.

Ideally, many of the NPM modules which have to use special logic for symlinks might now be simplified or even removed.

I'm curious as to the Use Case which has brought in a special npm-link and then a flag to turn off matching them or not. The purpose of symlinks in my mind was to not have to care at the build level.

What's the root issue here? A global module is linked into the local node_modules so that it doesn't have to be reprocessed? This all seems to be a Tech Debt of how child dependencies work within NPM, resulting in massive graphs of modules and files. It makes it difficult to "sell" npm as a package management tool imho. But I still love it and use it.

Wondering if there's a different way to look at the symptoms being caused by symlinks and fix the root problem instead. If there is an open ticket about this very thing feel free to reply and let me know what it is. I'd be interesting in researching into a fix.

[ylg]

symlinks work for us on both macOS and various Linuxes, both npm and yarn (not as extensively tested on npm as we're moving away from that on all projects now).

[coomysky]

It works to me just setting

resolve: {
    symlinks: false
}

[joaoreynolds]

To make sure it wasn't my project that was buggy, I did a fresh install from create-react-app and then ejected it. After adding a few extra transform plugins (which you can see in the config below), I then setup the link with yarn instead of npm (though I believe either would work as my regular project is not using yarn). However, I still ran into the same issues and the only way I could get everything to work was this (here's an outline of changes made to the default create-react-app webpack.config.dev.js):

resolve: {
  //...
  symlinks: true //<-- UNLIKE OTHERS ON THIS ISSUE, I HAD TO SET THIS TO TRUE
},
//...
module: {
  //...
  rules: [
    // Process JS with Babel.
      {
        test: /\.(js|jsx)$/,
        include: [
          paths.appSrc,
          fs.realpathSync(paths.rsCommonModule) //<-- I CREATED THIS VARIABLE IN config/paths.js to reference my linked module
        ],
        loader: require.resolve('babel-loader'),
        options: {
          cacheDirectory: true,
          "presets": [ //<-- I FOUND THAT I HAD TO DECLARE PRESETS AND PLUGINS HERE INSTEAD OF MY package.json (this may be a babel-loader bug, not sure)
            "react-app"
          ],
          "plugins": [
            "transform-decorators-legacy",
            "transform-object-rest-spread"
          ]
        },
      },
  ]
}

I then had to install all babel plugins and presets in my linked module - annoying, but I can live with it. But on a side note, the eslint-loader runs fine and will lint my linked module without needing to install eslint plugins.

[tony]

On webpack 3 with yarn workspaces,

javascript resolve: { symlinks: false }

made things click. nice

[the-spyke]

I have the same issue in my project. It it a monorepo of several modules on the same level with cross references. If ModuleA depends on symlinked ModuleB (which will be by default in case on npm 5 and file specifier), during compiling ModuleB's code Babel will try to resolve presets in Node style and fail.

How should I deal with module resolution in monorepos?

[ChristiaanScheermeijer]

I had the same issue using an ejected react app. However, it seems to be working when I include the realpath instead of the absolute path to the target dependency.

{
  test: /\.(js|jsx|mjs)$/,
  include: [paths.appSrc, fs.realpathSync('node_modules/package')],
  loader: require.resolve('babel-loader'),
  ...

[mick-feller]

Just want to give my 2 cents as well, at first the symlinks: false didn't work for me.

After some more digging i saw that in the resolve section i had the following setup:

resolve: {
        alias: {
             someAlias: 'alias path'
        },
        modules: [
            path.resolve(__dirname, '/app'),
            path.resolve('node_modules')
        ],
        symlinks: false
}

turns out that there is a big difference between absolute path loading in modules in the resolve section vs relative loading see this article: https://webpack.js.org/configuration/resolve/#resolve-modules

So with that setup it failed my build since it couldn't find the actual files in my symlinked directory.

After changing it to:

resolve: {
        alias: {
             someAlias: 'alias path'
        },
        modules: [
            path.resolve(__dirname, '/app'),
            'node_modules'
        ],
        symlinks: false
}

it worked perfectly for me, even my webpack dev server picks up the changes and refreshes what it needs to do.

Maybe it helps for someone who runs into this.

The reason why i'm adding my app to resolve modules is so i can reference pretty much anything from root level, so in my bundles i don't have to do:

../../someModule/index.js

instead i can just simply:

someModule/index.js

in case someone is wondering why i use that setting

[iwarner]

Using Webpack 4 I did not use the symlink: false in resolve

but simply had to use

    include: [
      fs.realpathSync('node_modules/component')
    ]

[jdpigeon]

For some reason, over the last couple months the exclude solution stopped working for me. The fix was simply to switch exclude to include!

include: /node_modules\/(?!module-name)/

[n8agrin]

@coomysky's approach worked for me. https://github.com/babel/babel-loader/issues/149#issuecomment-320581223

[loganfsmyth]

The issue here is most likely that .babelrc files in Babel 6 only apply to files nested in folders within the .babelrc's folder. This means the only option in Babel 6 is to put the configuration directly in your webpack.config.js.

As of Babel 7, this is restricted even further, and .babelrc files will also not apply to child packages, but we've also added support for project-wide babel.config.js files, so I'd recommend users who wish to compile node_modules and linked packages use those.

[chovy]

What should I put in babel.config.js?

[MrCoder]

What should I put in babel.config.js?

I had a .babel.rc at the project root folder. I just renamed it to babel.config.js and that fixed the problem. Within the file it has:

{
    "presets": [ 
        ["preact-cli/babel", { "modules": "commonjs" }]
    ]
}