Multiple //= require statements in JS/CSS in JEKYLL_ENV=development should result in multiple <script>/<link>s, like in Rails

[Nowaker]

• [ ] This feature is not on the latest version

• jekyll 3.8.5

• jekyll-assets: 3.0.12

Request

Cite from Rails documentation

Source.

In development mode, assets are served as separate files in the order they are specified in the manifest file.

This manifest app/assets/javascripts/application.js:

//= require core
//= require projects
//= require tickets

would generate this HTML:

<script src="/assets/core.js?body=1"></script>
<script src="/assets/projects.js?body=1">
</script><script src="/assets/tickets.js?body=1"></script>

Explanation

The way it's implemented in Rails is best suited for development:

1. Fast reloads - no need to compile the whole tree (SCSS + its all nested requires), as each asset is accessed directly, and can re-use the cache when a file has not changed.
2. Convenient in development - no need for sourcemaps when working on direct source code.
3. Resolves a problem with --incremental builds in Jekyll when modifying blah.js that is //= required by main.js. #596

Thanks for considering this! And thank you for jekyll-assets!

[envygeeks]

This would be a Sprockets issue as we don't directly provide requires.

[Nowaker]

I don't know if what Rails does is part of Sprockets, or custom Rails code wrapping Sprockets to achieve this result.

All in all, this issue is meant to be a feature request, not a bug report, so please consider this as an option in the future. Thanks!

[envygeeks]

Since Sprockets does all of the //= logic on our behalf the request would have to go through them, Rails would indeed support it through them so you'll have to provide more debug logs to show how it's broken and then I can talk with Scheems and see what's going on.

[Nowaker]

@envygeeks I don't understand your request. I didn't say anything's broken. This is a feature request.

[envygeeks]

Is there a benefit to doing this @Nowaker?

[Nowaker]

@envygeeks The three points in Explanation part of the ticket are the benefits.

[envygeeks]

# 1 isn't an issue Sprockets won't recompile the whole tree (or shouldn't) # 2 is only mitigated in certain circumstances (and only for Pure JS that isn't transpiled, or CSS) # 3 is a whole other ticket

That's why I asked if there were any better reasons.