object-assign: no such file or directory

[anorudes]

Module build failed: Error: ENOENT: no such file or directory, open '/home/anoru/git/project/object-assign'

more details: babel/babel-loader#242

[simonkberg]

As mentioned in the other issue, downgrading to 8.0.2 solves it, so it seems to be related to the addition of jspm support.

[rgrove]

I'm also experiencing this issue. I don't use HMR, but this occurs when running my CSS and JS gulp tasks in parallel.

Running either task by itself works fine, but running them in parallel results in all sorts of module loading errors like this one. The errors are inconsistent from one run to the next, but it seems like postcss-import's jspm support is doing something that breaks module resolution for other code running in the same process. I can confirm that downgrading to 8.0.2 resolves the issue.

[MoOx]

object-assign is included as a normal dependency of this package and require() reference is normal too. I guess the recent add by @swernerx broke something. @swernerx any idea?

[eugene1g]

object-assign is the first dependency used in the code. There is nothing wrong with it, and it's not actually missing, but the resolution of dependencies seems to happen at the root of the userland project - and node_modules is not considered. If I symlink object-assign from node_modules/ into the root project dir, then it's found and the next dependency fails.

Not much to go on for now, sorry. I haven't even triaged whether the problem is within webpack/postcss/babel - just that the resolving issue doesn't happen with 8.1.0 and happens with 8.1.1/2

[swernerx]

Puh, that looks like a though one. I am actually not sure where this is coming from.

Especially the timing / race condition / parallel related comments make me wonder what is actually happen here.

"object-assign" is not used by "pkg-resolve" at all. But as I understood it's not really related to this package but to some kind of setup of the environment (looking in the wrong paths). "pkg-resolve" uses both "jspm" and "npm" to resolve packages. Probably there is some issue that the npm resolver is not actually able to work in parallel with two different setups?

We first have to identify were this error is thrown from. Anybody has some stack trace or reproducable code fragment? I can't see it here - even when running some tasks in parallel in Gulp.

[tarikjn]

Same issue, verified to happen since 8.1.1+, 8.1.0 is not affected.

[dominictobias]

Same issue with 8.1.2, even if I just require in postcss-import into my webpack (v2) config and don't use it, it breaks babel-loader:

Module build failed: Error: ENOENT: no such file or directory, open '<path>/object-assign'
        at Error (native)
    Error loading <path>/object-assign as "object-assign" from <path>/node_modules/babel-loader/index.js
 @ multi js

Edit: downgrading to 8.1.0 works

[simonkberg]

I've been trying to triage this bug for the past couple of hours, but honestly - this is the dependency tree the JSPM-integration introduces:

└─┬ postcss-import@8.1.2 
  └─┬ pkg-resolve@0.1.14 
    └─┬ jspm@0.17.0-beta.16 
      ├── glob@6.0.4 
      ├─┬ jspm-github@0.14.7 
      │ ├── expand-tilde@1.2.1 
      │ ├── netrc@0.1.4 
      │ ├─┬ request@2.53.0 
      │ │ ├── aws-sign2@0.5.0 
      │ │ ├─┬ bl@0.9.5 
      │ │ │ └── readable-stream@1.0.34 
      │ │ ├── caseless@0.9.0 
      │ │ ├─┬ combined-stream@0.0.7 
      │ │ │ └── delayed-stream@0.0.5 
      │ │ ├── forever-agent@0.5.2 
      │ │ ├─┬ form-data@0.2.0 
      │ │ │ └── async@0.9.2 
      │ │ ├── hawk@2.3.1 
      │ │ ├─┬ http-signature@0.10.1 
      │ │ │ ├── asn1@0.1.11 
      │ │ │ ├── assert-plus@0.1.5 
      │ │ │ └── ctype@0.5.3 
      │ │ ├─┬ mime-types@2.0.14 
      │ │ │ └── mime-db@1.12.0 
      │ │ ├── oauth-sign@0.6.0 
      │ │ └── qs@2.3.3 
      │ ├─┬ rimraf@2.3.4 
      │ │ └── glob@4.5.3 
      │ ├─┬ tar@2.2.1 
      │ │ ├── block-stream@0.0.9 
      │ │ └── fstream@1.0.9 
      │ └─┬ which@1.2.9 
      │   └── isexe@1.1.2 
      ├─┬ jspm-npm@0.28.13 
      │ ├─┬ request@2.58.0 
      │ │ ├── aws-sign2@0.5.0 
      │ │ ├─┬ bl@0.9.5 
      │ │ │ └── readable-stream@1.0.34 
      │ │ ├── caseless@0.10.0 
      │ │ ├── extend@2.0.1 
      │ │ ├─┬ har-validator@1.8.0 
      │ │ │ └── bluebird@2.10.2 
      │ │ ├── hawk@2.3.1 
      │ │ ├─┬ http-signature@0.11.0 
      │ │ │ ├── asn1@0.1.11 
      │ │ │ └── assert-plus@0.1.5 
      │ │ ├─┬ mime-types@2.0.14 
      │ │ │ └── mime-db@1.12.0 
      │ │ └── qs@3.1.0 
      │ ├─┬ rmdir@1.1.0 
      │ │ └─┬ node.flow@1.2.3 
      │ │   └─┬ node.extend@1.0.8 
      │ │     ├── is@0.2.7 
      │ │     └── object-keys@0.4.0 
      │ └── tar@1.0.3 
      ├─┬ jspm-registry@0.4.1 
      │ ├── rsvp@3.2.1 
      │ └── semver@4.3.6 
      ├─┬ liftoff@2.2.1 
      │ ├── extend@2.0.1 
      │ ├── findup-sync@0.3.0 
      │ ├── flagged-respawn@0.3.2 
      │ └── rechoir@0.6.2 
      ├── minimatch@3.0.0 
      ├── ncp@2.0.0 
      ├─┬ proper-lockfile@1.1.2 
      │ └── err-code@1.1.1 
      ├─┬ sane@1.3.4 
      │ ├─┬ exec-sh@0.2.0 
      │ │ └── merge@1.2.0 
      │ ├─┬ fb-watchman@1.9.0 
      │ │ └─┬ bser@1.0.2 
      │ │   └── node-int64@0.4.0 
      │ ├─┬ minimatch@0.2.14 
      │ │ ├── lru-cache@2.7.3 
      │ │ └── sigmund@1.0.1 
      │ ├─┬ walker@1.0.7 
      │ │ └─┬ makeerror@1.0.11 
      │ │   └── tmpl@1.0.4 
      │ └── watch@0.10.0 
      ├─┬ systemjs@0.19.29 
      │ └── when@3.7.7 
      ├─┬ systemjs-builder@0.15.18 
      │ ├─┬ babel-plugin-transform-es2015-modules-systemjs@6.9.0 
      │ │ └─┬ babel-runtime@6.9.2 
      │ │   └── core-js@2.4.0 
      │ ├── data-uri-to-buffer@0.0.4 
      │ ├─┬ es6-template-strings@2.0.0 
      │ │ └── esniff@1.0.0 
      │ ├── glob@7.0.3 
      │ └─┬ rollup@0.25.8 
      │   └─┬ source-map-support@0.3.3 
      │     └── source-map@0.1.32 
      └─┬ traceur@0.0.105 
        └── semver@4.3.6 

Let's ignore the fact that jspm is a pre-release package: how many people actually use JSPM to warrant introducing this kind of change, causing many regressions for average package consumers? I'm positive one of these packages is doing something fishy, like overloading the module loading, but it's a maze to debug.

I'd say revert these changes and figure out a better way to handle the resolving of JSPM packages, if it's really actually required.

[timothyallan]

Same issue as @dominictobias here, simply including any version > 8.1.0 in my webpack borks everything.
npm install postcss-import@8.1.0 to the rescue for now 😟