fix(css): trim esbuild's minified css

[intrnl]

Description

Trims the end of esbuild's minified CSS output such that it doesn't end with a new line

Example below is the result of an inlined CSS, import './style.css?inline'

Before:

// esbuild minifier also turned this into a template literal so it can do a literal newline to save one character
const F=`h1{color:red}
`

After:

// matches the output of Lightning CSS
const F="h1{color:red}"

Additional context

None.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[patak-dev]

We also have an extra line on minified JS. I think if we would like to be consistent, we could go the other way around and add an extra line break to the minified output of Lightning CSS. @ArnaudBarre what do you think? I don't know how important it is to be consistent here.

[ArnaudBarre]

I'm surprised by this trailing line of esbuild in minify mode, what is the reason? If the reason is only legacy compatibility I'm fine with removing it (for me there is no need to sync CSS/JS behaviour if the reason for this extra byte is not the same)

[patak-dev]

I don't know why a new line is added in JS or CSS. I don't think we should change this in a patch release as it may cause snapshots or simple CSS tests to fail in downstream projects. It could be good to have the same for both CSS engines (no need to follow JS as you suggest), but I don't know if it is worth it, we will also be outputting a different result from plain esbuild or Lighting CSS and that may also be confusing.

@intrnl would you tell us more about your use case? Is it only to make this consistent?

[intrnl]

would you tell us more about your use case? Is it only to make this consistent?

@patak-dev yep, I was messing around with inline CSS and thought it was somewhat odd that you would have a trailing newline on it, so I made this pull request

the comparison to Lightning CSS's minifier where it doesn't output a trailing newline didn't occur to me until later on, I just thought to mention it as well.

[sapphi-red]

I believe it's because POSIX expects it.
https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline
For example, git diff will show a No newline at end of file warning.

If we would like to make it consistent, I vote to adding the line break.

[intrnl]

hmmm, could we try differentiating between minifying ?inline CSS imports and the usual CSS minification?

The reason why I even opened this PR to begin with is so that esbuild and terser doesn't minify the JS strings to be like so:

// esbuild
const styles=`.foo{color;red}
`;

// terser
const styles=".foo{color;red}\n";

[ArnaudBarre]

But CSS and JS will not run in POSIX. And I don't know if a lot of people commit minified code. And this doesn't cause an issue when inlined.

[intrnl]

I do not find the minified output to be ideal for something that's being inlined, there's a newline that can be removed and it saves one byte on esbuild and two bytes on terser

[patak-dev]

We discussed the PR in a team meeting. We think that it is a good idea to avoid the line break when the style is inlined in the JS asset. But the extra line should be there for generated JS or CSS assets.

[intrnl]

I've pushed a change that would retain the linebreak for emitted CSS assets specifically, let me know if there are any other blockers for this pull request.