ncc: Accessing `module.id` breaks

Log from the UI https://zeit.co/olstenlarck/tunnckocore-release-now-v2/agkrauawz

Error while initializing entrypoint: TypeError: u.startsWith is not a function
    at Object.<anonymous> (/var/task/user/index.js:152:281)
    at Object.<anonymous> (/var/task/user/index.js:153:30)
    at __webpack_require__ (/var/task/user/index.js:21:30)
    at Object.<anonymous> (/var/task/user/index.js:130:19)
    at Object.<anonymous> (/var/task/user/index.js:146:30)
    at __webpack_require__ (/var/task/user/index.js:21:30)
    at module.exports.module.exports.module.deprecate (/var/task/user/index.js:85:18)
    at Object.<anonymous> (/var/task/user/index.js:88:10)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)

About this issue

  • Original URL
  • State: open
  • Created 6 years ago
  • Comments: 24 (11 by maintainers)

Commits related to this issue

Most upvoted comments

The goal is that ncc just works for the cases where regular Node.js works. Even a slight change in semantics like what you are proposing will introduce surprising behavior.

ncc should introduce zero surprises when going from node program.js to ncc run program.js.

Re: extra transpilation steps. Yes, that’ll be cumbersome. In that case you might want to go with Webpack directly, or go with TypeScript, which we intend to support (#31), if that covers your use-cases.

ncc should introduce zero surprises when going from node program.js to ncc run program.js.

Got it.

Basically, I don’t need and don’t want more than Nodejs v8 or v10+ and writing everything in ES Modules so it can be future proof from now, even if I die accidentally 😄 (bad black humor joke? ;d) I don’t want build steps that’s why I use esm loader to make it work for the cjs users. But for last 2 years I was always thinking to create similar thing to ncc, based on Rollup (as this started).

And yes, I’m also excited about Node.js supporting ES modules! And ncc will mirror that support.

tunnckocore-release-now-v2 uses esm npm package. esm assumes that module.id is a string https://github.com/standard-things/esm/blob/880e03105f20d767d49b620717a2c78888ff2aa7/esm.js#L29, particularly calls it’s startsWith method. In pure node.js env it is true - module.id in a string indeed. But when webpacked, that id is a number. You can test it by nccing console.log(typeof module.id, module.id);. A solution can be replacing module.i with String(module.i) in https://github.com/webpack/webpack/blob/e3e8a68dabc102d7f67fd4c5584baf293b21cddf/buildin/module.js#L16.

CCing @igorklopov who can help debug

Can think for a repro, but probably the most basic thing, starting from the example and definining @now/node@0.1. But anyway, I’ll try it tomorrow if it is still happening. Thanks.