Comments (22)
As far as debugging a preset, I usually use getWebpackOptions
which just maps to config.toConfig
as @psachs21 mentiond:
module.exports = neutrino => {
console.log(neutrino.getWebpackOptions());
};
I think having a --debug
flag would be nice, and could probably be used to show an object diff between presets:
const alpha = ({ config }) => config.entry('index').add('src/index.js');
const beta = ({ config }) => config.entry('index').prepend('babel-polyfill');
const gamma = ({ config }) => config.entry('index').add('webpack/hot/dev-server');
// Neutrino v5.alpha .use()
neutrino.use(alpha);
neutrino.use(beta);
neutrino.use(gamma);
(Maybe a diff like this would be useful?)
# ––– neutrino.use
- {}
+ {
+ entry: {
+ index: [
+ "src/index.js"
+ ]
+ }
+ }
# ––– neutrino.use
{
entry: {
index: [
+ "babel-polyfill",
"src/index.js"
]
}
}
# ––– neutrino.use
{
entry: {
index: [
"babel-polyfill",
"src/index.js",
+ "webpack/hot/dev-server
]
}
}
from neutrino.
@SpencerCDixon I think we can iterate on it later. Maybe --debug config.plugins
so you can filter the diff to only plugin changes idk. I'll prototype something for v5.
from neutrino.
@eliperelman I like the idea of a coloured diff, although that could easily be generated by existing diff tools as simply as:
neutrino build --debug --presets a,b > before.json
neutrino build --debug --presets a,b,c > after.json
favorite-diff-tool before.json after.json
At a minimum, let's output the result of getWebpackOptions()
as you said above.
I think the most important change to make is cultural. Get people - especially newcomers - into the habit of printing the webpack config to see the effects of the presets and options they're enabling, so that neutrino
isn't a magic black box (like Grunt, Yeoman and create-react-app) and they actually learn what they're working with.
from neutrino.
I had some similar issues and found it helpful to output the config object. You can do this by adding adding a custom neutrino config like so:
\\ neutrino-custom.js
module.exports = (neutrino) => {
console.log(neutrino.config.toConfig())
};
And adding that to the presets (as the last one)
It's not ideal, and a flag on neutrino is cleaner, but it may unblock you.
from neutrino.
dumping the config after each modification would be cool. I haven't used it enough yet to judge if it would be better, but doing config = middleware(config)
with "vanilla" webpack might be a bit easier to grok than chained webpack, dunno, could be a lot worse, probably more error-prone
from neutrino.
+1 to having a debug/verbose mode which could just show snapshots of before and after applying middlewares. Even better I think would be showing diffs nicely formatted to reduce noise. What do you think @eliperelman of adding that to the use()
func on the neutrino object? Check for a DEBUG=neturino:*
env variable and if present show a nice diff
from neutrino.
hahahahah wow. Love it :-)
from neutrino.
@SpencerCDixon OMG wow
from neutrino.
So one thing to think about: if I'm trying to debug I probably don't want to see a dif between EVERY preset. But I might want to be able to see the changes between 2 or 3. If possible to use something a tad more advanced than just --debug
I think that would be useful. But even just a --debug
as a first step would be solid.
from neutrino.
@wmadden you're totally right on the diffs, this should be handled externally. I had a local implementation working that I just wasn't happy with, so I'm glad you raised this.
Regarding echoing the JSON to stdout, I just need to make sure that there aren't any console.logs that will intermingle with the data, and this should be easy enough. I also think a more appropriate flag is needed, maybe --config-only
.
from neutrino.
I just realized that we can't spit out JSON, since Webpack configs are code, not necessarily all data. Gonna need to think this through a little more.
from neutrino.
In order for this to be solved, we have to avoid conflating two things which we are currently doing:
- Outputting a Webpack configuration
- Viewing a Webpack configuration
They may seem the same, but the problem lies in that you cannot just echo a Webpack configuration and have it work, since it relies on the scope and context of its creation. So to require a Webpack configuration, you can use the API (proposed v5 syntax):
const Neutrino = require('neutrino');
const api = new Neutrino();
api.use(alpha);
api.use(beta);
api.use(gamma);
// or alternatively by pulling from package.json
require('./package.json').neutrino.presets.map(preset => api.use(preset));
module.exports = api.getWebpackOptions();
Getting a string of the Webpack options is possible from the CLI, but then is not consumable by Webpack.
from neutrino.
Fair enough. I think it'd be worthwhile giving people a way to view a representation of the webpack options, even if it's not usable as an input to webpack.
from neutrino.
@wmadden agreed, I'm working on it as we speak. Probably under --inspect
.
from neutrino.
Resolved with #86.
from neutrino.
Sorry to resurrect an oldie…
In debugging / sanity checks, I've too have found myself wanting a dump of the working webpack config - mostly to determine if I'm dealing with a webpack issue or a neutrino one.
but the problem lies in that you cannot just echo a Webpack configuration and have it work, since it relies on the scope and context of its creation.
@eliperelman I'm sure this is correct, but can you elaborate, or provide an example? Just trying to wrap my head around it. Are you saying an working config output is impossible to generate?
So, I started with something like
cat webpack.config.js | echo "module.exports = " &> webpack.config.js && neutrino build --inspect >> webpack.config.js
…and quickly realized bits like this were going to be a problem:
babel: {
transform: function () { [native code] }
},
Ultimately I was looking for something like neutrino build --dump webpack.config.js
from neutrino.
I did something like this:
var cfg = {
...
};
console.log('-----------');
console.log(JSON.stringify(cfg, null, 4));
console.log('-----------');
module.exports = cfg;
from neutrino.
I still think this in tricky territory that we just don't have the resources to support. In order to generate a working webpack.config.js from ejection, that means needing to dump into package.json, and get a bunch of references right, as well a string-building a config.
It's entirely possible to dump the config currently, either using --inspect
, or adding a middleware at the end with neutrino => console.log(neutrino.config.toConfig())
, it's just not usable from a webpack config file.
from neutrino.
I strongly feel --inspect
is a feature we need to improve. I agree an entirely working eject function is likely very hard and not worth the effort - but some tweaks to dump the correct values for plugins (see #328) would go a long way. What is dumped now is not the actual plugin config.
However that's a dupe of #328, which really needs changes in webpack-chain first (which is neutrinojs/webpack-chain#25).
I experimented locally with a few approaches to try and improve the situation, but they were all kind of hacky and I reached my yak shaving allowance for the month before I had time to come up with something better.
from neutrino.
Agreed.
from neutrino.
v8.3.0 has just been released, which backports the upcoming Neutrino 9's improved --inspect
feature, as --inspect-new
.
from neutrino.
The command didn't help me for other configurations besides webpack, namely the configuration-builder for jest
.
To others looking for an general way to eject from any webpack-chain
configuration, here's what I came up with:
const neutrino = require("neutrino")
const Config = require('webpack-chain');
console.log(Config.toString(neutrino().webpack(), { verbose: true }));
console.log(Config.toString(neutrino().jest(), { verbose: true }));
// etc.
from neutrino.
Related Issues (20)
- Issue: alias and config externals HOT 3
- Webpack 5 support HOT 5
- Tests fail because of CRLF-LF HOT 4
- Switch from eslint-loader to eslint-webpack-plugin HOT 3
- Optional chaining doesn't work out of the box HOT 2
- Allow specifying karma files option without removing the tests file specification neutrino use HOT 1
- Cannot use same babel plugin multiple times HOT 2
- Jest: custom moduleNameMapper entries should have priority
- rollup HOT 3
- Prettier breaks Neutrino webpack chain indent style HOT 1
- OTF fonts not supported by font-loader middleware HOT 3
- Updating React to v17 HOT 2
- nodejs build doesn't includes dependencies HOT 1
- Dependency Dashboard
- Alternative output without deleting other files HOT 1
- Support webpack-dev-server v4 HOT 3
- Build library for the browser HOT 1
- fullScreen make the app crash on armhf HOT 1
- Npm start failed to launch the project ! HOT 2
- Neutrino still under development? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from neutrino.