search

terser / html-minifier-terser

actively maintained fork of html-minifier - minify HTML, CSS and JS code using terser - supports ES6 code
https://terser.org/html-minifier-terser
MIT License
376 stars 30 forks source link

Update demo site #82

Closed sibiraj-s closed 3 years ago

sibiraj-s commented 3 years ago

Update demo site. Page now uses alpine.js.

sibiraj-s commented 3 years ago

@DanielRuf . do you have any opinions on using standardjs, prettier, migrating the build to rollup etc?

DanielRuf commented 3 years ago

alpinejs is something I'm currently working with at work.

Can you describe the motivation and advantages of these changes? Just so we know why we decided to do this step.

@DanielRuf . do you have any opinions on using standardjs, prettier, migrating the build to rollup etc?

Are these things which make contributions easier? Personally I don't like prettier (well, it is opiniated) but maybe I am just too old and not a fan of new things.

Do these solutions as setup help to make faster and easier releases? I'm happy to discuss the best way forward.

DanielRuf commented 3 years ago

I know that Grunt, browserify and so on are a few old solutions. And I have used rollup in another project fresh from the start. But will the migration work? You may know better than I do.

sibiraj-s commented 3 years ago

I know that Grunt, browserify and so on are a few old solutions. And I have used rollup in another project fresh from the start. But will the migration work? You may know better than I do.

There should be no issues during migration and also maintaining compatibility should be possible as well. and we can provide multiple builds as well, such as esm, cjs for modern systems.

Do these solutions as setup help to make faster and easier releases? I'm happy to discuss the best way forward.

It's the usual, having items like standardjs config enables more rules, catch obvious errors and etc. I chose standard.js because it is widely used, popular, and not very strict by default and with eslint we can always extend. I will help catching lots of errors upfront even with contributions, definitely worth adding it.

And prettier(not a big fan either) is optional, thought it might help in maintaining codestyle with contributions.

Can you describe the motivation and advantages of these changes? Just so we know why we decided to do this step.

A lot changed since this package originally written. I am thinking about rewriting the same in modern es6 syntaxes, modules etc. (obviously without compromising the compatibility). This will help us in long run to maintain the package and easier for contributors too. And this change is just a first step. Also not big fan of raw html templates, difficult to go through. since IE will officially be dead in few months. We can also leverage latest features like script modules etc.

DanielRuf commented 3 years ago

and we can provide multiple builds as well, such as esm, cjs for modern systems.

Sounds good.

It's the usual, having items like standardjs config enables more rules, catch obvious errors and etc. I chose standard.js because it is widely used, popular, and not very strict by default and with eslint we can always extend. I will help catching lots of errors upfront even with contributions, definitely worth adding it.

And prettier(not a big fan either) is optional, thought it might help in maintaining codestyle with contributions.

Ok, this makes definitely sense and is definetely a good way to make maintenance and contributions easier.

And this change is just a first step.

Souns like a good plan =)

since IE will officially be dead in few months. We can also leverage latest features like script modules etc

Definitely a good idea since this will lead to less issues as we will not support older Node and browser versions in the longterm and the overall ecosystem has to move on.