chore: rewrite bundle as node script

[uxder]

It was a bit hard to follow the npm scripts so I propose this change:

• Rewrite the npm scripts as node scripts so it is easier to maintain and follow.
• Removal of nodemon to watch files and instead consolidate to browsersync watching
• Replace rollup with esbuild

[stevenle]

this is where i feel like we're re-inventing the wheel and i'd suggest we re-evaluate whether gulp makes sense.

[uxder]

I don't mind gulp if that is preferred but in this case, I personally find a simple node script is much easier to follow how things are setup especially in cases like this where we have integration with browsersync watching.

Put another way, writing this file in gulp would more or less the same file but add another abstraction and I don't really see what value gulp would add.

[stevenle]

Put another way, writing this file in gulp would more or less the same file but add another abstraction and I don't really see what value gulp would add.

Some benefits I see in gulp:

• gulp can handle file watching and running tasks in series or parallel (or both) 1 line gulp.task('build', gulp.parallel('build:js', 'build:css'))
• gulp tasks feel more idiomatic to me. if i want to figure out how the "js" is built, i'm looking for a gulp task like "build:js" (or I'd check the console output which tells me which task is being built)
• if a user only wants to build a single target, gulp can handle that automatically, gulp build:css, whereas a custom script would require major rework

here's an example gulpfile i'm using across oak projects:
https://gist.github.com/stevenle/e6cea927fa91716563306e9b4407fc63

I just feel like gulp is more feature rich than what's currently available in this script, and I can do more if I need to without having to write too much code.

[uxder]

Okay, yeah I can see if you want to go and more to tasks like you have, it would be easier to do in gulp which makes sense for starter. Let me update this with gulp.

[stevenle]

before you put too much effort into rewriting this i'd suggest getting @jeremydw 's take on this since he seemed keen on not depending on gulp. i personally think gulp is worth using since it's basically just a task runner and it frees up package.json from looking too messy.

[jeremydw]

For the record I liked how we were able to get things working without writing any code, and just running scripts invoked in package.json. That was before we realized we had more complex requirements around bundling and processing. I suppose, it's fine to depend on gulp if it helps stay organized.

I agree with Scott's notion about using a simple script, but after reading Steven's comments I agree it might help to have separate gulp tasks for invoking the CSS build, JS build, both, etc. Scott, that was something I didn't think of when you pinged this to me earlier.

[uxder]

Yup sounds good. I haven't had much need to messing with gulp beyond getting JS / CSS going in a project so I thought simpler is better but on second thought, Steven's makes a good point and I think the starter should be easily expandable and to easy pick up. :)

[uxder]

Okay this is updated with gulp now. Let me know if you have any further feedback.

[stevenle]

Oops before you submit, could you double check that the TS output location is correct? I took a quick peek at tsconfig.json and it says outDir is dist/js.

[uxder]

Thanks for catching that. Looks like it was picking up a file I had generated earlier.

I've fixed this but the JS file generated from the ts build is not cleaned up. Here is what happens right now:

• tsc build to /dist/js/main.js
• esBuild takes the /dist/js/main.js and builds /dist/js/main.min.js

The main downside is that main.js which we don't need is included into the /build folder.

We can:

• add a deletion task after esBuild to delete main.js
• have tsc build to a different location like ts_build (or something). It could also be src/ts/ but then we get compiled js files alongside our ts.
• Go back to tsc -noEmit and just compile twice

@jeremydw Another option might be to have an exclusion rule to staticRoutes so we exclude main.js from the build.

[uxder]

Submitted a bit early. Given the three options (but maybe there are more), I personally lean towards just compiling twice and using -noEmit. It might add some small time to the compilation but I haven't found it noticeable and it makes the code easier to follow.

[stevenle]

I just checked amagaki.js and looks like the entire dist/js folder is exported as part of the site, so I think the tsc generated files should output elsewhere (gts uses build/ as its default).

[uxder]

I don't think we want to export out the tsc outputted main.js to the build folder since it's not needed as part of the build.

We could export it to some other folder likets_build but I feel it's a bit messy to have another folder just for this purpose.

Deleting is possible but again, I am feeling a bit that compiling twice with -noEmit is probably an acceptable trade-off to having the extra folder or adding this complexity to the build process.

[stevenle]

Ah yeah sorry I forgot that ama uses build/ for its deployments. I think something like ts_build is acceptable. Or we can use a subfolder within dist, e.g. dist/ts_generated_output/<output files>. Deleting can create artifacts if the workflow fails, e.g. if tsc builds some files but not all, and the "delete" never happens, we still get a dist/js/ folder that contains unwanted files, which then gets mapped to in amagaki since any file in dist/js/ will become part of the site.

(I don't think we should compile twice, there it creates an arbitrary slowness in the build workflow, which I consider bad practice.)

[uxder]

FYI, I'm going to sit on this a bit more as I noticed a few more issues while using this on a project.

• It may not necessarily be specific to this PR but the interaction with browser sync seems a bit delay and annoying.
• I want to add notifications since it is easy to miss type errors

[jeremydw]

@uxder - in #21 I've moved this to use gulpfile.ts and esbuild, similar to our other projects. I left the original browser-sync configuration as-is as I haven't noticed any major issues with it. Not sure if any fixes from this PR need to be applied still or if this was fixed thanks to the gulp and esbuild upgrade.

[jeremydw]

Slight update – I need to remove some additional node scripts (the sass scripts are not needed anymore as they are handled in gulp); will do so shortly.

[uxder]

Is browsersync working okay?

I tried this config on a project but the main issue was that browsersync was flaky. I ended up disabling browsersync integration in that project.

[jeremydw]

It is working OK at the moment, but I haven't put it through deep testing.

1. Clone https://github.com/blinkk/amagaki-starter
2. npm install
3. npm run dev

Now I can make CSS or YAML edits and things autoreload. I just tested it with vim (which uses swap files) and things seemed to work fine; but it's just a limited test.