Plugin.json scripts no duplicates

frissdiegurke

I'd like the scripts property within plugin.json to ignore duplicates.

A value like this ["public/scripts/globals/", "public/scripts/"] should first include all files within public/scripts/globals/ and afterwards all files within public/scripts/ without including those within /public/scripts/globals/ again.

I need this for my nodebb-grunt rework which is nearly able to get released
If it doesn't get implemented I'd have to use a more ugly file-structure for my module prototype.

psychobunny

Wouldn't it just be OK to do the parent one, it implies you're including that subfolder already anyways

frissdiegurke

But it wouldn't ensure the order which I need to do for defining global variables (I basically need a variable defined for all other files).

psychobunny

Could this work for your usecase?

globals.js

MyAsyncFunction(function() {
 MyPlugin.stuff = X;
  window.trigger('myplugin:init');
});

lib.js

window.on('myplugin:init', doThis);

Probably a good idea to avoid globals anyways?

frissdiegurke

Ok, I'll get a bit more into details...

I have a compile-step (grunt task) that replaces occurrences like @{id} with my-plugin.
I want this to apply to as few files as possible (no performance issues, but applying to all files could produce issues when you really want to use the string @{id} somewhere - may be for a different super-language of javascript).

This is why I created a sub-directory globals (in fact it's called meta in my case) which gets this compile-step applied.

Now I want to use the plugin-id within files outside of this globals directory and without hard-coding it (you should be able to change your plugins name by just editing the package.json when done properly).

Because of this I use var currentModuleID = "@{type.name}/@{id}"; within the globals directory and reference this variable within the other files.

psychobunny

You mentioned a hack to figure it out for your usecase, how does that look? I'm just saying this because adding a subfolder to run first to get globals set and then requiring the parent folder to ensure load order sounds like something that doesn't really make sense.

Ima defer this to @baris / @julian though. But I do think you could probably figure out an alternative?

frissdiegurke

For the hack I'd either need to create a directory parallel to public/scripts/ (like public/scripts_globals/) or to public/scripts/globals/ (like public/scripts/foobar/ and require all other scripts to be in there).
An alternative I'd use rather for now would be to apply the compile-step to all files within public/scripts/. This would also get rid of the global variable.
But as mentioned it could drive the developer nuts if he/she/it tries to get such a string...

I just thought this might be an overall nice feature (since it's pretty common in such arrays with other frameworks) if it's not too hard to achieve.

Without you cannot define the order of generic files if and only if they share the same parental directory. Sounds a bit inconsistent to me... Otherwise I'd not asked

So the question regardless of my use-case should be: "Should we allow developers to define the script-execution order?"

frissdiegurke

I decided to go with applying the compile-step to all client-side scripts options.

Nonetheless this might be nice to have