Wow great stuff, thanks so much. Yeah I was killing myself to find a way to output the sourcemap file, should have come here sooner! I’ll try it out.
antalvarenga
peerreynders
Let us know if the source maps work (don’t have Postgres installed right now, so couldn’t fire up your project). It may be simpler to remove exorcist and leave the source map in line.
0
antalvarenga
peerreynders
Separating them is useful for production. When they are separate the browser should be able to detect the source map but there is aways room for hiccups.
The last line of app.js is
//# sourceMappingURL=app.js.map
0
amnu3387
Yes - probably learning the “lower level” of calling directly the build tools from the CLI (& respective configs) would have been (and probably for me still warrants trying to learn it) a better option that jumping immediately from brunch to webpack - I will check this further thanks.
(having said that, webpack & its loaders do so much heavy lifting I don’t even feel like going to the gym anymore - sourcemaps, separate bundles, css/scss dependencies/requirements from JS, fonts, image compression, dev/prod separation in config… I’m hoping that the next iteration will also output cups of coffee on demand)
1
antalvarenga
Yep this seems to work fine! Thanks.
One thing - here:
const config = {
ignore: ['deps/**','node_modules/**']
};
Shouldn’t it be '../deps/**' ?
0
peerreynders
There is a problem - but that’s not the solution. In your build.js throw in
const minimatch = require('minimatch');
other packages (i.e. babel-core) already use it so it should already be there; then throw in
console.log(
minimatch(
resolve('./node_modules/lodash/lodash.js'),
'node_modules/**'
)
);
console.log(
minimatch(
resolve('./node_modules/lodash/lodash.js'),
'**/node_modules/**'
)
);
console.log(
minimatch(
resolve('../deps/phoenix_html/priv/static/phoenix_html.js'),
'../deps/**'
)
);
console.log(
minimatch(
resolve('./js/socket.js'),
'**/deps/**'
)
);
console.log(
minimatch(
resolve('../deps/phoenix_html/priv/static/phoenix_html.js'),
'**/deps/**'
)
);
and see what happens when you $ node build.js
So it should have been ['**/deps/**','**/node_modules/**']
see also Globtester
Update This still works:
browserify({debug: true}) // turn on source maps
.add(resolve('./js/app.js'))
// .add(resolve('./js/socket.js'))
// .add(resolve('../deps/phoenix_html/priv/static/phoenix_html.js'))
// .add(resolve('../deps/phoenix/priv/static/phoenix.js'))
.transform(babelify.configure(config), babelrc)
.bundle()
.pipe(exorcist(mapPath))
.pipe(target);
So it seems that Browserify is smart enough to follow the breadcrumbs through the various package.json files to find phoenix_html.js and phoenix.js. Now when you comment out socket.js the bundle does get smaller but as soon as you remove the comment in the original assets/js/app.js for
import socket from "./socket";
the bundle is back to its original size. That means that Browserify automatically loads imports for you (assuming they use the correct path in the first place). So just specifying only the entry file (assets/js/app.js) should be enough.
1
antalvarenga
peerreynders
The ignore list excludes files from transpilation and Babel passes them on as is. npm packages for the browser are already supposed to be transpiled and if you look at phoenix.js and phoenix_html.js you’ll notice that they are already transpiled. So there is no need to process them - and excluding them reduces that transpilation load.
Yesterday Babel was complaining about something in the Phoenix JS but that seems to have gone away now.
Note that Chrome may mark the imports as errors in the source map view because browsers are only now starting to support <script type="module"> and are breaking things along the way. For example ECMAScript strongly prefers that the .js extension is omitted while it has to be specified in the browser.
1