JavaScript best practices

[makma]

As a web developer, I'd like to use JavaScript heavily in my site powered by Statiq.

How to integrate into the build/framework pipeline:

• JavaScript code,
• TypeScript code with transpilation,
• JavaScript linting, bundling, minification, and transpilation (latest ES + polyfills),
• CSS minification,
• CSS preprocessors support (LESS/SASS).

[st3phhays]

i am curious about this too as I am looking to implement gulp.js to take care of a lot of the minification/bundling. There are a lot of great plugins I use to really shrink down the size of things and get rid of unneeded css, as well as manage some of the external libraries (like bootstrap). I am unsure though of where to add this into the build pipeline to work with Statiq.

[daveaglick]

My thinking at the moment is to add support to Statiq Web for running CLI apps out of process, with some default commands for common bundlers like webpack, gulp, etc. but extensibility to add your own. Statiq itself already has a pretty powerful StartProcess module, so hopefully this is mostly rigging that up to a default pipeline in Statiq Web, providing some conventions around settings that drive it, and figuring out a few good default scenarios.

I've still got some open questions I'll need to experiment with like which files the bundler should be run on (input or post-output), whether it should stay resident in the background or get run at the end of every generation, etc. I'll need to experiment a bit to figure that part out.

TL;DR: this is probably the next thing I'll work on, so expect to see some movement here soon.

[daveaglick]

I think I've got a decent design for this:

• One or more "scripts" can be defined similar to the way templates are defined.
• Scripts are Config<string> so they can be conditional (I.e. by returning null).
• There are four types of scripts:
  • BackgroundScripts - executed at start and continues to run (I.e. webpack watch).
  • StartScripts - executed at start of execution and blocks execution.
  • EndScripts - executed at the end of execution.
  • DeploymentScripts - executed after normal pipelines but before deployment pipelines, only when deployment pipelines run.
• As with other settings, scripts can be defined in settings files, using the bootstrapper, etc.
• Default scripts will be added for gulp, webpack, rollup (any others?) - they'll use a condition that checks if the corresponding configuration file is present and then return the appropriate command if it is (for example, gulpfile.js) or null if it isn't (which won't run any script).
• I'll need to write some guidance on how folders interact with certain kinds of scripts - for example, if we have gulp process all the files in an "assets" folder, we probably don't want to treat those files as assets that get copied directly to the output folder.

[daveaglick]

A couple adjustments:

• These will be called "tasks" ("scripts" didn't seem quite right) - while that could potentially get confusing with .NET Task I think the usage is different enough it'll be okay. That also leaves the door open for other non-CLI based tasks in the future.
• Defining a task won't use a Config<string> delegate because there won't be a document available at this point. Instead, it'll use a delegate that takes a IExecutionState.

Work has started and is progressing quickly as anticipated. The first step was splitting out process launching from the StartProcess module so it could be used outside the module for launching tasks.

[daveaglick]

I ended up going with a more specific "processes" term for this - it turns out that tasks vs. .NET Task was breaking my brain, and the more I thought about it, the more I don't really want this to be other than external processes anyway (running arbitrary code is what modules are for).

Anyway, it's alive!

Still have some polish to do, will hopefully ship a first version with support for custom-defined processes this weekend and then start looking at defining some in-the-box ones (kind of like Hugo Pipes).

[daveaglick]

Support for "processes" has shipped, I'll try to get the concept documented in the next day or two. I decided to go ahead and ship the underlying feature before adding any specific process support for stuff like gulp, webpack, etc. I'll open new issues for those. In the meantime, you should be able to integrate whatever preferred tooling you use if you know the command line for it.

There are four bootstrapper extensions that light this up depending on when you want the process to run:

• .AddBackgroundProcess(string fileName, params string[] arguments)
• .AddProcessBeforeExecution(string fileName, params string[] arguments)
• .AddProcessAfterExecution(string fileName, params string[] arguments)
• .AddProcessBeforeDeployment(string fileName, params string[] arguments)