Minimize CSS when running lektor server with NODE_ENV=production

[dairiki]

Currently, the generated CSS is minimized when running lektor build, but not when running lektor server.

If one publishes their site using the "Publish" button in the Lektor GUI, one publishes un-minimized CSS.

This PR minimizes the CSS in lektor server mode if the $NODE_ENV environment variable is set to "production".

---

NOTE: This PR is stacked on PR #4. It should be merged after that one. (It may also require rebasing, depending on how #4 is merged.)

[frostming]

This PR minimizes the CSS in lektor server mode if the $NODE_ENV environment variable is set to "production".

When will that be set? Can it be set from any tool are must be set by user manually?

[dairiki]

This PR minimizes the CSS in lektor server mode if the $NODE_ENV environment variable is set to "production".

When will that be set? Can it be set from any tool are must be set by user manually?

For lack of better ideas, yes, I was envisioning it being set manually, or in some external way.

E.g. I now use pdm (thank you) to manage my Lektor projects' virtual environments. Configuring a pdm script to run lektor server makes it easy to configure per-script environment variables).

---

I'm open to alternative ideas for switch modes. Some ideas:

• Lektor-tailwind could default to production-mode, minimizing the built CSS, unless, say, $LEKTOR_DEV is set. ($LEKTOR_DEV is an environment variable that, when set, turns on hot-reloading and verbose logging in the Lektor dev server.)

• Instead of keying off an environment variable, we could Lektor's extra_flags (controlled by the --build-flag or -f command-line switch) to control behavior. E.g. lektor server -f production .

[frostming]

• Instead of keying off an environment variable, we could Lektor's extra_flags (controlled by the --build-flag or -f command-line switch) to control behavior. E.g. lektor server -f production .

I prefer this method. Let's do it.

[dairiki]

The more I think about this, the more I prefer using $NODE_ENV.
As far as I can tell, its used for exactly this purpose is common in JS-land.

Refs:

• https://nodejs.org/en/learn/getting-started/nodejs-the-difference-between-development-and-production
• https://webpack.js.org/guides/production/#specify-the-mode

Various magics whereby JS transpilers treat NODE_ENV as a compile-type constant, thus removing debug code (upon minimization) from code transpiled with NODE_ENV="production":

• https://babeljs.io/docs/babel-plugin-transform-node-env-inline/
• https://esbuild.github.io/api/#platform
  E.g. with test.js:

  console.log(process.env.NODE_ENV == "production" ?  "PROD" : "DEV")

  npx esbuild --minify test.js produces:

  "use `strict";console.log("PROD")`;

---

Also, I think it would minimize confusion if lektor build and lektor server behaved the same.
So, I suggest:

• lektor build and lektor server should default to the same behavior (with respect to CSS minimization)
• lektor build and lektor server should both respond to the same flag or envvar (whatever is decided)

Note that Lektor flags can take an argument, so we could do something like

# minimize CSS
lektor server -f production:true
# or
lektor build -f production:true

# non-mimize CSS
lektor server -f production:false
# or
lektor build -f production:no

(and the default can be whatever we decide...)

[frostming]

Also, I think it would minimize confusion if lektor build and lektor server behaved the same.

But it's also a common practice in JS world that commands for different purpose set NODE_ENV to different values. For example, vite dev implies NODE_ENV=development while vite build implies NODE_ENV=production.

lektor server is more a development command to me(starting a dev server like vite dev), so non-minify makes more sense to me.

[dairiki]

@frostming Good enough! Thank you!