Open Stack

Thomas, please find a couple of comments inlined below.

On Tue, Jun 23, 2020 at 15:05 Thomas Goirand wrote:
[...]
> Hopefully, you understand the problem isn't specific to distributions,
> but also to any sysadmin which is pushing such a library bundle online.
>
> We need to avoid NPM because it's broken by design. Not really because
> of NPM itself, but because of how it's used in the JS community:
> clarelessly.
>
> Every language has its own management system, each being worse than the
> other. By far, I would consider NPM the most horrible one I even met.
> The result is always that:
> - NPM gets multiple versions of the same library (because that's how
> things are expressed)
> - NPM discards the older one randomly (because only one version can be
> there), and...

NPM can nest dependencies within a dependency when there are
unsolvable conflicts, resulting in many node_modules directories.
There are options to force a flat install, without nested node_modules,
but you may get incompatible versions resulting in a broken build.

Well I've tried that without success to package the >1600 nodejs
dependencies required by grafana-5.2.3 .

> - the result gets compress and bundled with a tool that isn't even safe,
> into a single file (which is faster to load).
>
> Yes, I do consider nodejs-uglify as something dangerous that one should
> try to avoid: there's been proven security hole with it (please don't
> trust my words, and do your own research on it, it's easy to find, a few
> years ago someone even opened a thread in the
> debian-devel at lists.debian.org list about it).
>
> On 6/23/20 5:51 AM, Akihiro Motoki wrote:
>> I think the problem is not which system(s) we use
>> for dependency management. What we need is to define a proper
>> versioning strategy in the project at some point of maturity of a
>> software.
>
> The dependency management tool you're going to use is going to have a
> huge influence on how you manage the dependencies. With NPM, one clearly
> decides the way of: "I don't care how or what, I just care about the
> shiny page result".
>
>> Back to packaging, I am also not sure whether the xstatic mechanism
>> should continue.
>> All updates in their upstreams need to be checked (manually now) and
>> we usually tend to be behind it even if there is a security update.
>> "Double packaging" is not efficient. Horizon upstream packages JS
>> libraries into xstatic and distros packages it into their packages.
>
> The effort using the XStatic thing was to be able to de-embed javascript
> from the rest of Horizon. I wouldn't mind changing to another system,
> but that system *MUST* provide the same enhancements we saw with XStatic:
>
> 1/ Enable de-embedding of JS libraries from Horizon (and plugins).
> 2/ Being easily fetched for testing in our (python based) gate.
> 3/ Artifacts can easily be replaced by the distro-specific version.
>
> I currently don't see another way than XStatic. If you do, please share.
> We've discussed multiple times that it is contributor time consuming,
> we're all aware of it but found no other approach so far.
>

Could XStatic somehow works for typescript (Angular) or JSX (React) ?
If I understand correctly, those frameworks require a toolchain to
transpile the code to JS.

Otherwise it seems like the packaging concern you are raising may
be too much of an issue as such frameworks are quite an important
requirements for many modern JS applications.

Considering how entangled the JS requirements are, is it really worth
it to bother with individual packages compared to a bundle produced from
a lock file where a bot like dependabot can propose updates when a
dependency has an known issue?


Another solution would be to avoid JS entirely and to use a safer language
like Elm or PureScript which seems to have a saner approach to
dependencies, but that is not an option for existing JS code base :-)

Regards,
-Tristan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200623/e862e7ac/attachment.sig>