Cli-microsoft365: spfx project externalize exceptions to patterns

[baywet]

There are libraries that do not follow the naming patterns we're trying to match.
A few examples are:
Suggested:
"moment-timezone": "https://unpkg.com/moment-timezone@^0.5.27/index.js",
"moment": "https://unpkg.com/moment@^2.24.0/moment.js",
"tinycolor2": "https://unpkg.com/tinycolor2@^1.4.1/tinycolor.js"

Should be:
"moment-timezone": "https://unpkg.com/moment-timezone@^0.5.27/builds/moment-timezone-with-data.min.js",
"moment": "https://unpkg.com/moment@^2.24.0/min/moment.min.js",
"tinycolor2": "https://unpkg.com/tinycolor2@^1.4.1/dist/tinycolor-min.js"

I was thinking about adding a rule dedicated to handling those exceptions. It won't be perfect but at least we'd be able to start addressing the "odd" recommendations. Thoughts?

[waldekmastykarz]

Isn't there a way to retrieve those names from somewhere like package.json?

[baywet]

for the examples I provided the package.json main points to the suggestion we've made.
We could try the jspm/main and jspm/files properties as well. But then if we get multiple results, how could we decide which one is authority?

[waldekmastykarz]

I would prefer to avoid exceptions, because once we go down that route, there is no end to it and it will be close to impossible to maintain it.

[baywet]

Agreed, it's a rabbit hole we should try to avoid for as long as we can.
The only things I can suggest:

1. the Rencore API to tell the difference between the types of modules (es6, systemjs, commonjs...)
2. looking as well at the jspm/main property https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm#prefixing-configuration

This way we could implement something like

1. get me all the potential files (module, main, and jspm/main), also "make" variations with .min, .bundle ...
2. get the module type of all those possibilities thanks to the API
3. use the first one that's a umd or amd module or a script
4. give up if none of them are successful

With this approach we should be able to cover more cases, and provide better suggestions for the ones that have multiple possibilities.
The only thing is that it requires changes on Rencore's API, and I'm not sure if this is possible/how long it will take/etc...
What do you think?

[waldekmastykarz]

1. would be the easiest one because that API does that internally already. The detected type is just not exposed externally. Let me adjust that and I'll update you when it's available

[waldekmastykarz]

We've updated the API and a new version that exposes the detected type is available at https://scriptcheck-weu-fn.azurewebsites.net/api/v2/script-check

[baywet]

Great! do you have a mapping of the values it returns?

[baywet]

ok so after some poking around your API and guessing here is what I think it returns and the action we should take based on the return information:

• CommonJs, SystemJs => not supported in browser, move on to another file if we can, give up if we don't have more files
• UMD => return direct link to file, but should handle dependencies and global names ideally, would you be able to also expose the global name in the API?
• AMD => return direct link to file, no need to handle dependencies
• ES2015 => return direct link to file, and I'm not sure whether we need to handle dependencies??

Am I missing anything else?

[waldekmastykarz]

Correct, these are the four values supported at the moment. I'm not sure how easy it is to handle dependencies, so let's leave that aside for now and see if it's needed. I could see if I can get the global name for UMD in the API.

[baywet]

thanks, and to be clear "module" and "script" are gone now?

[waldekmastykarz]

Yes. Now we have the 4 values you mentioned, plus non-module if the detected script is not a module.