🏗✨：add nps start task

[DerekNonGeneric]

(mostly self-explanatory altho i have tried to collect a lot of scattered lore dictating its “idiomatic” correctness)

“Running Locally” section of our portal documentation describes usage of this task, but had yet to be implemented:

[…] Run this from within the project workspace root directory:

nps start

Once the script finishes building the documentation site, one may visit it at http://localhost:4000/. […]

we're not only going to be fulfilling this need here, but also getting rid of the old way we had been doing this — our new “Start” task is intended to serve as our project's “Default” task, was pulled from our pre-existing “Serve” task, which was originally in tasks.json of /.vscode/, but as we're continuing our plans on significantly augmenting it… https://github.com/OpenINF/openinf.github.io/blob/d3210b42b0db5b095a8f04dd734001097f5ec11c/.vscode/tasks.json#L1-L26

…that will no longer be how we run project tasks as we'd like to achieve more independence from VS Code (eventually becoming IDE/editor-agnostic)^1

for additional context, read the bottom of the “This solution” section of original nps readme:

You don't have to use the start script if you don't want. Note that if you're writing a node application, you're likely using start for starting your server. In that case, you can create a default script which will be run when nps is run without arguments (so effectively it'll work just the same). But if you'd prefer, you can use whatever you wish. […]

the above wouldn't really make much sense unfamiliar w/ the npm ecosystem, so also read the following:

• https://docs.npmjs.com/cli/v10/commands/npm-restart
• https://docs.npmjs.com/cli/v10/commands/npm-start
• https://docs.npmjs.com/cli/v10/commands/npm-stop
• https://docs.npmjs.com/cli/v10/commands/npm-test

also, check out how @gulpjs displays when the default task is running:

• https://gulpjs.com/docs/en/getting-started/quick-start/#result

[netlify[bot]]

❌ Deploy Preview for gh-pages-openinf failed.

Name	Link
🔨 Latest commit	2cb5c33b20fdc3aadff667e0ebe7704971538bcf
🔍 Latest deploy log	https://app.netlify.com/sites/gh-pages-openinf/deploys/6672695a0e72b90008c846d1

[DerekNonGeneric]

memory still hazy from vacation, but i think we still may need to ensure that the SCSS is getting compiled and may need to actually create an actual script to run

aside: whoops, found mistakes in https://github.com/OpenINF/openinf.github.io/blob/live/build/tasks/compile/build-portal.mts

——-

i think we should introduce https://esbuild.github.io/getting-started/ (for sanity)

[DerekNonGeneric]

i just noticed that this is going to need some refactoring; see similar:

• https://github.com/ampproject/amphtml/blob/main/build-system/tasks/build.js
• https://github.com/ampproject/amphtml/blob/main/build-system/tasks/serve.js
• https://github.com/ampproject/amphtml/blob/main/build-system/tasks/default-task.js

this is tentatively how it was looking for us, but obviously some adjustments are necessary:

[DerekNonGeneric]

i am thinking we should enable incremental regeneration (not only for posts, but assets too)

🔗 https://jekyllrb.com/docs/configuration/incremental-regeneration/

[DerekNonGeneric]

i will do a follow-up wrt augmenting nps start task and flesh out the server

[DerekNonGeneric]

(not planning to roll back ruby just for netlify, they can upgrade their tools)

[DerekNonGeneric]

(not planning to roll back ruby just for netlify, they can upgrade their tools)

just to clarify, i’d still like to ensure our web services stay up and continuous delivery processes stay green, but relying on netlify (who doesn’t always have the tool versions we need) to build the portal is simply untenable; we need another solution…