We're currently running a full scan of every package on npm for more cases of the virus originally found in eslint-scope. We've unfortunately already found one. As we find new cases, we'll be reaching out to package maintainers and updating this repo:
Babel 7.4.0 is out, with a lot of shiny new features!
- 🎉 Update to core-js 3
- 🔤 TypeScript 3.4 support
- 🕵️♀️ Stage 3 Static Private Methods
- ❓ Stage 1 Partial Application
Our hope is that this will end up being an over abundance of caution. The quick work of both the eslint team and npm have hopefully stopped this before it had a real chance to take off, and it could happen to anyone. Please take the time to turn on your 2FA!
@gr2m
@bitandbang
Not only that, since RunKit snapshots the entire state of npm, you can actually freeze the bug forever: so if the test does fail, you can easily rewind to previous package/node version combinations and see what exactly causes:
@dehora
Have you taken a look at RunKit? We’ve *specifically* tackled unifying files and notebooks (the problem on slide 25) to the point where notebooks can import each other safely since top-down order is guaranteed via entire VM-level code rewinding:
@WietseWind
Yes we pushed a major update that significantly improves performance. You should be able to throw 30 runkit embeds on a page now and they take the same memory as just one did before. We’ll be sharing more details soon. And yeah, we’ll definitely make the error more intelligible!
@tarasm
Hi Taras, we’re currently working on a revamped syntax transformer that should give you much more control of the transformations. This coupled with the in flux nature of Babel right now (the 7 upgrade) is why its taking a little longer than would be expected. Sorry for the delay!
@NeverwinterMoon
Sorry about that. We’re actively working on upgrading our infrastructure right now to support new syntax features. (Sadly, it’s been something we’ve neglected for too long)
You can read a little more about it here:
@retrohack3r
@bitandbang
@verdaccio_npm
@opencollect
it’s almost the built in node_modules resolver (and working on having that be 100% the case). available_modules is just the “global install path”. The top level number folder represents the entire state of the npm registry at that millisecond: it’s a temporal filesystem.
@linkibol
@inancgumus
@gatsbyjs
@codesandbox
Let us know if we can help, we recently shipped a huge update precisely for these kinds of use cases: loading 30 runkit embeds in a page is now as performant (both speed and memory) as just one. We’ve been optimizing for heavy multiple embed use.
@SMJSGaming
@kelechsky
Apologies for the delay. We’re having a bit of a hiccup at the moment processing packages. If you’re referring to demangler and std-node, they’re caught in our backlog. Once our issue is resolved we should get through our backlog fairly quickly. I promise we’re not ignoring it :)
@nazar_kulyk
Hi Nazar, yes that is definitely something we’d like to provide. It’s taking us a bit since we’d like to do it in a completely user-controllable way (that way you don’t have to wait for us to “support” the latest typescript).
@picsoung
@wilhelmklopp
We inline the code (donor is selectable) and show an image of the result. We’re going to ship an update later today that inlines environment details too (dependency versions, node version). Whatever you’d like us to include were open to it!
@retrohack3r
@bitandbang
@verdaccio_npm
@opencollect
Yeah you can actually manually traverse the filesystem if you want. With embeds, you can set the package time stamp and freeze all requires to that date. This is useful for filing bugs since it’s like using everything (even new requires) at the time the bug was found.
@Smetad_Anarkist
Hi Martin, your package is available now. We recently release Node 13 support, when new major version of Node are released it takes a while to reprocess packages, so sometimes newer packages get delayed too.
Sorry for the delay!
@shahidcodes
30 seconds per cell, so if you download in one cell and unzip in another you should be fine. We’ve had people download gcc and compile c files, so I think so you should be fine.
@ImagineBananas
If you’re using RunKit in an embed, then whatever site is hosting it. If you’re using RunKit directly, then probably whoever linked you to the document.
@mspanish
Not yet, but we know it’s a pain point and we’d like to fix it. We’re actually working on a big rearchitecture of embeds. If you’re using them a lot we could show you a beta.