js concat

[mikes-gh]

• We have a simple requirement to concat js files and minify. We already use excubo for scss.
• Can excubo web compiler do this?
• I looked at the code but it seems to only compile the last file in the list https://github.com/excubo-ag/WebCompiler/blob/5dd070e0696612e851186102bb03216aa732606b/WebCompiler/Compile/JavascriptMinifier.cs#L20

[stefanloerwald]

This is not a feature that's currently supported in Excubo.WebCompiler. The tool looks at all files provided in the command line individually and then performs compilation steps on them, e.g.: file.scss -> file.css -> file.min.css -> file.min.css.gz. This is the sequence you've identified in the code.

[elken]

It supports modern js so just use require or import?

[mikes-gh]

they are not modules just a series of functions in different files. Can I still use import?

[mikes-gh]

OK Im going to modulize the few functions I have. Just so Ive got this right I will export the functions in each file and have a central file listing all the imports that I will compile and all should work? Apologies Im not js centric

[mikes-gh]

when I compile with imports it just minifys the imports statement or am I misunderstanding.

[mikes-gh]

from the code it look like it just minifys

[mikes-gh]

closing in favour of concatenating

[mikes-gh]

Having finished the build task for concatenating it would be much cleaner in the tool itself. Is this something youd consider for PR. webcompiler ./Scripts/*.js would need a new config object output filename or something

[stefanloerwald]

To be honest with you, I'm not sure whether I like the idea so much. It not only adds complexity in the compilation, but also adds confusion as to what happens for e.g. webcompiler -r script1.js a/folder/with/something/in/it/ my_styles.scss --concat=merged.min.js (with the hypothetical flag --concat). webcompiler as it is right now just does something very predictable to each and every file individually. Only in scss will it combine multiple sources, but that's within the scss rules, not webcompiler. This isn't a hard "no". Maybe it'd be best to first talk about the design of this feature.

[mikes-gh]

The main driver for this feature is that the MADS library is really not maintained anymore. This extension sells itself as an xplat alternative to that library and that is one of the functions that it provides. Maybe the command line could look like. dotnet webcompiler ./scripts/*.js > ./scripts/app.js ./styles/app.scss -o ./wwwroot In my msbuild I actually run webcompiler once per file type so mine would be dotnet webcompiler ./scripts/*.js > ./scripts/app.js -o ./wwwroot dotnet webcompiler ./styles/app.scss -o ./wwwroot

[stefanloerwald]

The main driver for this feature is that the MADS library is really not maintained anymore. This extension sells itself as an xplat alternative to that library and that is one of the functions that it provides.

While the main motivation to develop this tool was to have a replacement for Mads unmainted webcompiler, it's not supposed to be a one-to-one replacement. It has by no means the same feature set, both in languages and in semantics of the command line arguments (e.g. this tool adds recursive search).

Maybe the command line could look like. dotnet webcompiler ./scripts/*.js > ./scripts/app.js ./styles/app.scss -o ./wwwroot In my msbuild I actually run webcompiler once per file type so mine would be dotnet webcompiler ./scripts/*.js > ./scripts/app.js -o ./wwwroot dotnet webcompiler ./styles/app.scss -o ./wwwroot

This wouldn't work because the > symbol will make the shell redirect the output to the specified file.