Open zindel opened 6 years ago
Hi @zindel!
Thank you for spelling everything out so clearly. I've started working on solving number 1 (Parse errors) here
I have a few questions:
For number 2: Is there something better we could do? if we know the exact preprocessor that the user would ideally use couldn't we automatically apply the correct preprocessor without having to make the user configure it. We could output a message like: utilizing preprocessor "style-loader!css-loader" for file Y for css compatibility
.
Related to number 3: Since there are cases where we'd want to supply the browser implementation instead of the mock one, wouldn't --replace
be more accurate than --mock
.
@samouri Regarding the first suggestion, it looks quite magical. Also user may want to do it differently or handle the css with some other settings (for example style-loader!css-loader?cssModules=true
). I think the best we can do at a later phase is to have the --dry-run
mode of the fpack
(or some other binary) where it runs on the project & suggests the config.
The --mock
one. I agree that the name is less than ideal. I would offer we rename in a separate pull request though. --replace
sounds good. How about the --resolve
one?
@andreypopp @TrySound any opinion on this ^
I've been using fastpack lately with several projects and found out that error reporting is far from being perfect of even usable. Here are some ideas which I've got so far:
Parse errors Parse errors are received from the
Flow_parser
and then displayed by fastpack in a quite ugly manner:As you can see, it shows the file and the location(s) of the error, as well as the error text. Ideally, we would show the code frame and highlight (using color or some ASCII art) the location for each error in the list.
Parse errors - non-JS files The error message for the error above gets even uglier when fastpack consumes the CSS or static file, thinking of it as being JS. Here is an example:
Lots of misleading errors for such a short file! Imagine, how long is this list for the binary file. We definitely can do better here by handling the case when module doesn't have preprocessors (we expect all of them to return valid JS) + has some non-JS extension (
.less
,.sass
,.ts
,.png
etc). Moreover, we could suggest the--preprocess
command line argument if we see this instead of displaying the list of errors. For instance for the case above, we could say:Here is the list of extensions & loaders we could offer (fill free to add more :)):
.css
:style-loader!css-loader
.scss
,.sass
:style-loader!css-loader!sass-loader
.less
:style-loader!css-loader!less-loader
.ts
:ts-loader
.html
,.htm
:html-loader
.txt
:raw-loader
.woff
,.woff2
,.svg
,.png
,.jpg
,.jpeg
,.gif
,.ttf
:url-loader
orfile-loader
Suggest the mock package for node libraries Sometimes some of the 2+ level dependencies requires some of node.js base libraries, like
fs
orstream
. This may be a general error or done for reason, just accounting for the browser-specific mocks. It would be great if fastpack could detect those cases and make a suggestion alongside with reporting the resolve error. For example:Here is an example of possible pairs: https://github.com/webpack/node-libs-browser
Dump the last error & the last source file where it happened Finally, it may be useful to be able to dump the last error alongside with the JS source processed into the file (just like
npm-error.log
). I've been thinking about thefpack-debug/error.txt
andfpack-debug/source.js
. Maybe only when--debug
is provided. There are few reasons for it:Thoughts? Also, feel free to append to this list if you think something is missing here :)
Checklist: