Nothing here yet.
Nothing here yet.
No blogs yet.
The plugins located there are being built into Next.js or moved into the Next.js monorepo, eg next-css and next-sass have been built into Next.js. Preact has an alternative approach that works better (this example: https://github.com/zeit/next.js/tree/canary/examples/using-preact) We still have to update the repository, it's on the backlog of work to do.
Did some of your design decisions (first-class serverless support, Now, network optimizations) penalize you when adding features to Next.js? Overall we're never limited in possibilities. One of the great things about thinking about serverless support is that it helps ensure pages can scale infinitely, even when on-demand rendering. For example incremental static generation is partially based on what we could already provide users hosting on ZEIT. Now we're bringing these features into Next.js to allow everyone to take advantage of them. How do you know what to prioritize in the whole list of RFCs/next features that are going to land one day in Next.js? Generally we prioritize based on community need. For example the amount of 👍and replies + involvement from the community is very telling as to how much impact we can make by building out a feature we're thinking of. RFCs also allow for experimentation, as feedback allows us to adjust for community needs.
Overall the main thing that has been helpful for me is creating a proper office space inside the house. We all work remotely so we were already working from home. Noise cancelling headphones work pretty well, depending on if you have a lot of background noise. Also getting an external monitor and ensuring that it's at the right height and an ergonomic desk chair.
From the start we went all in on adding end-to-end integration tests for all features which has helped us scale development and increase confidence when shipping new versions. Besides that we've only added in more measurements to track, for example every pull-request gets a comment that shows how you're affecting bundle size of the Next.js runtime, the overall app at all and even node_modules changes: https://github.com/zeit/next.js/pull/11725#issuecomment-610375111
At ZEIT we use Checkly to run tests against every deployment that is made: https://checklyhq.com/ For the Next.js end-to-end tests we boot up the Next.js production server by running next start and then running tests using the wd package (webdriver). This allows us to run tests on multiple platforms against multiple browsers. Overall it depends on what you're trying to do. In general I personally prefer end-to-end tests as they ensure the end product works and doesn't depend on implementation details
The Next.js serverless build output was designed to be hosting platform agnostic. It can be used to host on any platform. It does require that you wrap an interoperability layer for the provider that you want to use and split the functions as there is no standard between hosting providers. There are some community tools to handle this wrapping for you (like the one you linked).
One of the biggest pain points users currently have is handling environment variables. We're aiming to solve this through this RFC: https://github.com/zeit/next.js/discussions/11106 Overall we're working on many developer experience improvements right now and solving some more complicated patterns. One example of this is that "paths in tsconfig.json and jsconfig.json is going to be supported very soon: https://github.com/zeit/next.js/pull/11293 Another thing that we're working on is even more documentation and example resources about general concepts in Next.js. Overall we closely monitor the Next.js community and talk with users of Next.js both large and small. This goes from Alexa top 100 sites to people building the website for their local bakery. This provides a lot of context into how we can improve the framework. Most of the features introduced in the past 2 years have been based on feedback from companies building Next.js applications.
I don’t think the requirement is very strong, but if the complexity is manageable, defense in depth ](https://en.wikipedia.org/wiki/Defense_in depth (computing)) ) is always a reasonable idea. Next.js on itself has many security benefits built in: The focus on JAMStack ensures that most of your code runs on the secure sandbox of the browser’s client. The pages downloaded from the edge is the same for every user, and as such, the security surface is reduced. i.e.: If you don't opt-in to server-rendering through getServerSideProps you're serving static files to users. React has excellent built-in protections for XSS, as evidenced by the verbose dangerouslySetInnerHtml – this is in stark contrast to the jQuery model, which popularized direct HTML and DOM manipulation of attributes and nodes. When using API pages deployed as serverless functions, each request runs in an independent VM context not shared by any other request concurrently, and the underlying containers are recycled frequently. Again, the attack surface is massively reduced. From an engineering perspective, we also have a security e2e test suite that we continuously run to ensure all the common attack patterns are considered.
We're actually working on many features, not just on static generation. We strongly believe there are major wins to make in scaling JAMStack and bringing static generation to larger applications in order to allow them to scale even further. Examples of this are: On-demand generating extra static pages: https://nextjs.org/docs/basic-features/data-fetching#fallback-true Incremental generation: https://github.com/zeit/next.js/discussions/11552 Preview mode: https://nextjs.org/docs/advanced-features/preview-mode Next.js is becoming more hybrid in that you get to choose per-page if you want it to be server-rendered on-demand or statically generated at build-time and then incrementally re-generated. The incremental re-generation case works for most sites backed by a CMS for example, whereas if you want to make the tradeoff you can move to on-demand generating it for each request. This allows for full flexibility and you're not tied to one solution or the other, for example you might start with on-demand rendering but then eventually move to static (and vice-versa)