ml5-library icon indicating copy to clipboard operation
ml5-library copied to clipboard

[devops] upgrade dependencies, starting w/ node

Open afogel opened this issue 3 years ago • 4 comments

Dear ml5 community,

Big fan of the project. At the suggestion of @shiffman , I'm opening up a conversation here: This is kind of a broader conversation issue. I'm trying to work on contributing an ml5 wrapper for the mediapipe holistic model and have run into some issues with dependencies.

I'm running apple silicon (m1 max/arm64) and am on OS Monterrey. Specifically, as I try to install and use an older version of node (v10.15) for development purposes on my apple silicon machine, I'm running into an internal error:

make[1]: *** [/Users/arielfogel/.nvm/.cache/src/node-v10.15.3/files/out/Release/obj.target/openssl/deps/openssl/config/archs/linux-x86_64/asm/crypto/aes/aesni-mb-x86_64.o] Error 1
rm 7a8fe2213509aee24b60f53cc9262fa803c1c2c6.intermediate
make: *** [node] Error 2
nvm: install v10.15.3 failed!

when I try to use a newer version of node (node v 12), I'm still running into issues, e.g. running npm run start gives:


> [email protected] start /Users/arielfogel/Development/ml5-library
> webpack-dev-server --config webpack.dev.babel.js

ℹ 「wds」: Project is running at http://localhost:8080/
ℹ 「wds」: webpack output is served from /
ℹ 「wds」: Content not from webpack is served from /Users/arielfogel/Development/ml5-library/dist
ℹ 「wdm」: wait until bundle finished: /
ℹ 「wdm」: wait until bundle finished: /
...
ℹ 「wdm」: wait until bundle finished: /

I'm wondering whether it might be worthwhile to bite the bullet and upgrade to the latest LTS version of node (v. 16.13.2). The reason for this is a few-fold:

tl;dr: I think it will help support contributions and maintenance for an already awesome project.

This will probably be a labour of love to some extent, given that some of the dev-dependencies are going to break on newer versions of node (it looks like node 14+ breaks a lot of the current dev-dependencies' dependencies).

One concern I have is if we can't rely on tests or don't have regression tests (#637 ), I'm afraid we may upgrade and not know if we incidentally broke something. That said, I would find it very helpful to make my own contribution if it were easier to get up and running. It kind of seems like this proposed change mostly impacts dev dependencies, but might have some implications for tensorflow, too.

If only web development were not so brittle 😮‍💨 ...

Curious to hear others' thoughts! Thank you for your consideration!!! 🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈🌈

afogel avatar Jan 13 '22 23:01 afogel

Hi @afogel !

I've not been super involved in ml5 recent times, but I've been mulling this one over a bit as well. A lot of your points totally resonate and I'm wondering if it actually raises some big potential opportunities and considerations we might discuss for imagining what is next for ml5.

As you've pointed out, there's a potential for a lot of features breaking as we make some of these dependency updates, but I think this could actually be more of an opportunity than a setback!

The web ML space is changing super rapidly and SO many new models have popped up (and a lot of older ones have been deprecated or are no longer maintained). For the last years, ml5 tried our best to collect these models from all the different parts of the web and provide our "friendly" wrapper around those different models. Many/most of those were tensorflow models, but a few came from other places -- we ended up having to juggle a lot of considerations related to this (e.g. breaking changes related to tensorflow version updates).

All that being said, I've been wondering how ml5 might "evolve" into its next phase if we were to map out what a "new" ml5 might look like, one that accepts that some of our "old" ml5 features might no longer exist (e.g. would ml5 still be ml5 w/out the sketchrnn?), but recognizing that it could open up new doors in other ways (e.g. supporting running ml5 in node on a server).

One thing we might also be able to do in imagining the next 'ml5' is to setup an easier foundation for testing and code conventions which might help with making it easier for folks to contribute and help maintain :)

Maybe this is a thread we might start in another issue, but I'll tag a few folks here @shiffman @yining1023 @bomanimc @tlsaeger for visibility. Maybe it's time for me to get on discord 🙈 😂 !

joeyklee avatar Jan 19 '22 02:01 joeyklee

Hi @joeyklee so wonderful to see you here!! Tagging @c-dacanay also because we just had this exact discussion yesterday!

shiffman avatar Jan 19 '22 13:01 shiffman

For reference, here are the deprecation warnings which I got after all of the updates in #1379, as well as the top-level package that loads this dependency.


from [email protected] npm WARN deprecated [email protected]: request-promise has been deprecated because it extends the now deprecated request package, see https://github.com/request/request/issues/3142

from [email protected] npm WARN deprecated [email protected]: Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details. npm WARN deprecated [email protected]: https://github.com/lydell/resolve-url#deprecated npm WARN deprecated [email protected]: Chokidar 2 does not receive security updates since 2019. Upgrade to chokidar 3 with 15x fewer dependencies npm WARN deprecated [email protected]: See https://github.com/lydell/source-map-resolve#deprecated npm WARN deprecated [email protected]: Please see https://github.com/lydell/urix#deprecated npm WARN deprecated [email protected]: The package has been renamed to open npm WARN deprecated [email protected]: See https://github.com/lydell/source-map-url#deprecated

from @tensorflow/[email protected] npm WARN deprecated [email protected]: Please upgrade to @mapbox/node-pre-gyp: the non-scoped node-pre-gyp package is deprecated and only the @mapbox scoped package will recieve updates in the future

from @tensorflow/[email protected] npm WARN deprecated [email protected]: core-js@<3.4 is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up t o 100x even if nothing is polyfilled. Please, upgrade your dependencies to the actual version of core-js. npm WARN deprecated @types/[email protected]: This is a stub types definition. fast-json-stable-stringify provides its own type definitions, so you do not need this installed.


I will look into replacing request-promise which is used in scripts/batch-update-p5webeditor.js. We already have axios for requests and cross-fetch for polyfilling fetch requests in dependencies.

I haven't put up a PR yet but I played around with updating the @tensorflow packages and it went surprising well. Their public API has barely changed between versions. They dropped built-in support for method chaining so we need to import their work-around or rewrite a few places that we use chaining.

lindapaiste avatar May 09 '22 00:05 lindapaiste

I started to play around with updating TensorFlow in #1383

Our code is mostly fine, but it's all of the external library dependencies that are going to be a pain. It might just be one line that needs to change, for example in StyleTransfer I had to move a dtype float32 conversion to a different place. But if the code is not in our control then we can't make those sorts of changes.

I will continue working on this.

lindapaiste avatar May 10 '22 22:05 lindapaiste

Update: we're building a new iteration of ml5.js with updated dependencies here and it uses Node 18.15.0. We're aiming to have the new version released by the end of the summer. I'm closing this issue for now and please move to https://github.com/ml5js/ml5-next-gen/issues/11 for latest updates on the progress!

Miaoye

sproutleaf avatar Jul 12 '23 01:07 sproutleaf