$ tree .
.
├── foo.js (will be bundle entry point)
├── bar
│ └── baz.js
└── node_modules
└── mypackage
├── package.json (has `main` set to `foo.js`)
└── foo.js (this is the entry point for the module `mypackage`)
$ browserify foo.js > bundle.js
$ cat debundle-config.json
{
"type": "browserify",
"knownPaths": {}
}
$ debundle -i bundle.js -o dist/ -c debundle-config.json
$ tree dist/
.
├── foo.js (is bundle entry point)
├── bar
│ └── baz.js
└── node_modules
└── mypackage
(no package.json)
└── index.js (this is the entry point for the module `mypackage`, not using a custom entry point though)
The above demonstrates the issue. When the entry points happen to be at the same level, everything is fine (ie, foo.js => index.js) However, if the initial entry point is some/long/nested/directory/that/ends/in/index.js, and this is collapsed to index.js, all the requires will be off because they expect that nested structure.
A package where this is the case is @blueprintjs/core, where the entry point is dist/index.js. Therefore, a bundle with blueprint in it s currently unable to be rebundled after debundling.
The above demonstrates the issue. When the entry points happen to be at the same level, everything is fine (ie,
foo.js
=>index.js
) However, if the initial entry point issome/long/nested/directory/that/ends/in/index.js
, and this is collapsed toindex.js
, all the requires will be off because they expect that nested structure.A package where this is the case is @blueprintjs/core, where the entry point is
dist/index.js
. Therefore, a bundle with blueprint in it s currently unable to be rebundled after debundling.