Serverless sounds perfect for our service: it doesn't run fulltime and we need You can just spin up 1000 servers instantly. Means that you have very high scalability: if you get 1000 simultaneous requests
Will spin up, handle the request and then kill itself after some time. Serverless you can define a function that will execute on request, the function I always wanted to try this cool technology called Which means that we had to rebundle your whole packageĬombination if you added a dependency. The costs grew exponentially as we became more popular, and we were caching by There were still some limitations and disadvantages to this 'ultimate' packager.
The service works and how you can make use of it. We wanted to make the packager service available for everyone. These packagers can be dynamically added. Then we have multiple packagers that do the bundling, The new system also got an architectural upgrade: we have one We did it! and I combined forces and created a common NPM bundler for WebpackBin and CodeSandbox! 1/2 /6X3hxamLyN- Ives van Hoorne April 22, 2017 After a lot of tweaking of this system we got it workingįor any(?) combination. Means that we manually added entry points, to make sure that webpack wouldīundle those files too. The "ultimate" packager retained the same functionality as our previousĪlgorithm that would add files to the bundle depending on their importance. We decided to combine forces and build the ultimate packager! webpack with entries System to support npm dependencies and we were having the same limitations. I did release CodeSandbox with this version though, and got in contact with theĪuthor of WebpackBin Christian Alfoni. Required by the entry point of the dependency in the first place. Require('react-icons/lib/fa/fa-beer') wouldn't work, because it was never That were not in the dependency graph of webpack.
Now there was still a big limitation with this system. This worked very well, and I got myįirst version with proper npm dependency live! During evaluation we would callĭll_bundle(:id) for every dependency. When you load a sandbox, we would first make sure that we'd have the manifestĪnd the bundle before evaluation. Than the diagram, mostly because I replaced installing dependencies with Implementation was much easier than expected!ĭependencies and spit out a JS bundle with a manifest. There was one advantage of this overcomplicated approach: the actual My first version didn't fit in my head, so I had to draw a diagram:
Npm serverless webpack how to#
So! I started thinking on how to approach this. I should'veĮxplored the possibilities first before dismissing the idea. Proof of its 'possibleness' I started putting more thought into it. I never dared to give proper npm supportĪ thought, because I thought 'it would be impossible'. Supported any dependency from npm, you could just define them in package.json
Npm serverless webpack install#
Install any dependency without performing magic. I didn't think it would be even possible to I was quite satisfied with the first version, and I thought it would be Was able to at least make two dependencies work in a sandbox environment. This, of course, is absolutely not scalable toĤ00,000 packages with different versions.Įven though this version was not very usable, it was encouraging to see that I I just installed the dependencies locally and stubbed every dependency call withĪn already installed dependency. This version of npm support was very simple. I really didn't know how to approach this, so I started with a very simple I'll explain how npm support started, what we have now and what we Work in any scenario, we did multiple rewrites and even now we can still improve Nowadays npm support is one of the most defining features of CodeSandbox, so I thought it wouldīe impossible to install an arbitrary, random amount of packages in the browser,Įven thinking about it caused my brain to block. I always left npm dependency support out of scope during
0 kommentar(er)
