Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--outfile option incompatible with current method for generating external sourcemap #996

Open
jackwanders opened this issue Nov 16, 2014 · 5 comments

Comments

@jackwanders
Copy link
Contributor

The README states that if the user would like to have their sourcemap pushed to an external file, as opposed to inlined in the bundle itself, they should use exorcist and pipe browserify's output through exorcist before writing the output file with >.

If the user makes use of the the --outfile (which doesn't currently offer any real benefit over >, but would if #995 were to be accepted :cough:), then this method of generating an external sourcemap isn't an option, as browserify no longer pipes to process.stdout and exorcist has no input on which to act.

It would seem that allowing browserify to directly create an external sourcemap file by either providing the --debug option with a filename as a value, or by adding a --debug-file option would be useful.

I don't know that this is directly resolvable within browserify, as sourcemap generation appears to be delegated to browser-pack, so I'm hoping that @substack or someone else equally familiar with both packages could provide some input as to whether this is possible, or if it's been discussed and rejected as a feature in the past.

Thanks.

@ghost
Copy link

ghost commented Nov 24, 2014

Then don't use -o? I don't see what's so hard about:

$ browserify main.js --debug | exorcist bundle.js.map > bundle.js

especially when the docs mention exorcist already and provide a handy example.

@jackwanders
Copy link
Contributor Author

Perhaps this issue would have best been withheld until after #995 was resolved one way or the other. As of right now, you're right, there's absolutely nothing wrong with piping through exorcist before dumping the bundle to a file with >.

However, if -o should ever provide some added benefits over >, then it would be reasonable to assume that some users would want to use -o without losing the ability to generate external sourcemaps.

@Macil
Copy link

Macil commented Nov 24, 2014

$ browserify main.js --debug --outfile >(exorcist bundle.js.map > bundle.js)

Not that this helps with #995.

@jasonkarns
Copy link

jasonkarns commented Sep 28, 2017

There are reasons why "simply piping to exorcist" is not ideal.

  1. Piping to exorcist eliminates any possibility of passing extra arguments to browserify through an npm-script (since they are just tacked onto the end of the command, and would thus be attached to exorcist instead of browserify).

    Given npm script: "build": "browserify main.js --debug | exorcist bundle.js.map > bundle.js"
    When running: $ npm run build -- -s foo
    Then the invoked command is: browserify main.js --debug | exorcist bundle.js.map > bundle.js -s foo which is clearly invalid.

  2. And again since exorcist doesn't accept an --infile option, it's impossible to split the two steps into separate npm scripts. The following is impossible:

    "build": "browserify main.js --debug -o bundle.js"
    "postbuild": "cat bundle.js | exorcist bundle.js.map > bundle.js"
    

    Ideally, this would work, thus allowing build to accept additional options as noted above (1). However, the postbuild script fails horribly because the shell will truncate bundle.js prior to cat running (in preparation of receiving the output of exorcist).

Both of these limitations are technically the fault of exorcist, which has steadfastly refused to address these issues: thlorenz/exorcist#22, thlorenz/exorcist#23, thlorenz/exorcist#24

Browserify could eliminate the headaches caused by exorcist by handling the sourcemap itself. In the years since browserify was created (and since this issue was first opened), plenty of other tools have popped up that all write their sourcemaps themselves. (babel and rollup to name two common ones) It is general convention now that the sourcemap be output to a file with the same name as the bundle, but with the .map suffix. Both babel and rollup default to an external sourcemap with the same filename. To force an inline sourcemap, inline is given to their respective --sourcemap options.

I propose browserify follow this convention: have --debug default to external sourcemap (accepting inline) as an argument to revert to inline sourcemaps. This would be a breaking change so another alternative would be to introduce a new option (--sourcemap) that follows the new convention and to deprecate the --debug flag and behavior at some point in the future.

@alundiak
Copy link

alundiak commented Dec 27, 2017

I can't use --outfile when path to file contains not existed yet folder.
Any ideas how can I configure it?

 "build-js": "browserify src/main.js --debug -o dist/bundle.js",

dist is not existed.

My workaround:

"scripts": {
  "build-css": "lessc src/my.less dist/my.css",
  "build-js": "browserify src/main.js -o dist/bundle.js",
  "prebuild": "mkdir dist",
  "build": "npm run build-css && npm run build-js"
},

And when I run npm run build, then prebuild is executed before and all is goo with browserify, But maybe there is a chance to configure browserify to create dist folder?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants