Conversation: features

[Bartmax]

I love the direction your are heading Mads. I want to share my opinions of what is needed for a great front end development experience.

Application source files:

Application/sctips/main.ts
Application/scripts/_otherfile.js
Application/scripts/admin.js
Application/stlyes/main.(less|sass|css)
Application/styles/variables.(less|sass|css)
Application/Images/logo.png
Application/root/favicon.ico
Application/fonts/customFont.ttf

Vendor library files, jquery, bootstrap, etc.

Sometimes you want to go with the source files of vendors, others you don't. Bootstrap and jQuery are great examples where you normally wants to use bootstrap.sass and customize from there but jquery.js and jquery.min.js are the only thing you need from jquery.

In the case of FontAwesome, you have 2 type of files that must be keep folder path relative. You need the font files (ttf, etc) and the .css/min.css file.

And then you have packages like modernizr where you include only the tests you need. The are two ways to work with packages like this one:

1. Via javascript dependency injection (you have everything in your output and load only what's needed)
2. You create a custom "bundle" of the needed tests.

Another type of packages may include extra files (sometimes optional) like images, theming, etc. Pretty sure you are familiar with them.

Based on all those I would like this tool to copy libraries (selectively) to output folder. So jquery.min.js and bootstrap.min.js ends up on wwwroot/libs/jquery but not bootstrap.css. Libs preserve relative folders so when I use font-awesome.css all font files are found.

If the library already contains a .min file I preffer to use what the package author provide instead of minifing myself. Hence if lib.js exists but not lib.min.js, I want lib.js to be minified but if lib.min.js exists just copy it.

In the case of bootstrap normally one creates a bootstrap-custom.sass file and import source files directly so compiling the bootstrap-custom.sass it all that's needed (i guess?)

Assets like favicon files and manifest.json, robots.txt, humans.txt etc only copy is needed. (recursive copy of files to root)

In the case of images, there's also optimization, there are multiple ways to do this. I think one good approach is to keep source non-optimized files on source and optimze them on build/copy (if necessary).

There is also html templates...

The output will look somehow similar to this:

wwwroot/app/main.min.js
wwwroot/app/main.min.css
wwwroot/app/admin.min.js
wwwroot/lib/jquery/jquery.min.js
wwwroot/lib/bootstrap/bootstrap.min.js
wwwroot/lib/font-awesome/css/font-awesome.css
wwwroot/lib/font-awesome/fonts/font-awesome.ttf
wwwroot/favicon.ico
wwwroot/favicon.png
wwwroot/robots.txt
wwwroot/humans.txt
wwwroot/images/logo.png

NOTE about bund/min libraries While you can of course have some mechanisms to bundle libraries like jQuery, etc. I will really don't like this approach because you now lost the ability to use cdn to serve those files.

NOTE about development minification Some people think that is better to have non-min files while developing. This is not true anymore with the use of sourcemaps, so I think having sourcemaps will really simplify things. Sourcemaps generation should be excluded and/or cleaned on release builds and excluded from publishing.

But, how to extend this? I like the plugin extension model that brunch.io uses. If you are not familiar, you just add a plugin and all files that are supported by that plugin will be used. An example would be: I want to jslint files on build. Maybe it may be possible to add a plugin system so I can say: js files from application (not vendors) run jslint in a particular order and returns success or not and block the build and returns an error. This can be used for images too, so if you add the "optimize image" plugins, all images are optimized during build, etc.

Each point given here I think it merits a whole separate conversation but I want to share my thoughts in general so you can let me know what are your opinion about this so I can understand what is desirable and what's not so I can see if any of this actually fits this tool/extension and help with it.

An option to use artifacts included on source control (ala webpack) will also be needed for some workflows, where a dependency on the package manager is not desirable on ci builds, which also speeds build time and make it for a less prone to errors builds. Something like: don't build if output exists and matches a checksum or something (implementation can be anything)

P.S.: In the future, I would love to see dotnet compatible package manager for front end dependencies (maybe NuGet. maybe something else) without the need of node at all. There's a cross plat tooling now with dotnet cli and I think that will be the perfect tool for the task in place.

personal note: I don't think there's a need to replace gulp or webpack, but yes to create a tool that automates the web development workflow from an asp.net perspective. If then this is better than those tools, fine. People can still use whatever it pleases.

[madskristensen]

Speaking of a xplat client-side library installer, did you see the Client-Side Library Installer proof of concept extension I wrote? It's not xplat yet, but will be

[Bartmax]

No, I didn't know about that extension. That looks like it will fill a lot of the gaps. I'll take a look and comment. Looks very promising!

[Bartmax]

@madskristensen as I promised, here my comments about packman extension.

I tried for very little and got blocked almost intermediately, it has a major problem (or I missed it). I can't get sass,less or source files from packages, i guess because it only uses cdns as providers.

I know I can create my "custom-package" url, but that's not what i want.

Some libraries like bootstrap, are meant to be "modified/customized" and you need the sass files.

Another issue i found is that package names, versions and files varies from cdn to cdn, I much rather choose to work with what the developer chosen and not some arbitrary name, this is a problem neither npm nor bower has.

It also looks like it might have some side-effects, I didn't tried but if I (or another developer on my team) switch from cdnjs to jsdelivr I'm pretty sure we will find issues when restoring.

While packman is pretty good, doesn't look like suitable for a simple, pretty basic use-case scenario, that is installing bootstrap for real actual development.

---

I will be trying using bower with the bundler/minifier extension and see how that goes. I'll keep you posted.