maybe its just me but the word next in there alone just has me thinking it could mean multiple things. If we go the route of nextRoot, i also think maybe nextSiteRoot or siteRoot might be worth thinking about as names instead of nextRoot. this also feels related to con 2 of solution 2. □ definitely feels like a nice-to-have, but it does seem like we have a nontrivial number of nx users.necessary evil for nx to spare all the other use cases extra complexity :'( +1 for documenting well.the nx outputPath option can be very confusing paired with all of these other dist-related/output-related settings. i think, no matter what, our monorepo support will have to be well-documented because i do still think people's approaches can be very complicated i.e. if distDir as a plugin input is only needed for monorepo setups like nx (and not for the majority of users), i think this should be ok.now that i think about it, this was actually pizzafox's approach (you may have noticed this when adding status stuff to the caching logic).obviously not functional outside of sites where the site is based from the project root and is in the project root. sounds like the current implementation. ![]() All node_modules at top level, Next in subdirectory.The following project types have been tested May not be possible: needs more investigation of Nx APIs. Pros: Doesn't need any special work by the user, or any config options.Solution 1, plus special case handling for Nx: try reading details of the workspace from the config.We can check the config to ensure that the user has set the value. Pros: Doesn't require any new config options.✅ Solution 1, but require that Nx users set the distDir to a specific value, which overrides the behaviour where it rewrites it to a parent directory that we can't work out.Allow the user to manually set a Next root and a distDir in the plugin config.Cons: doesn't solve the Nx issue, as the distDir can't be found from the config.Pros: Avoids the issue with next config not being a sibling of the publish dir.Allow the user to manually set a Next root directory.Both of the are the case by default with Nx, which changes distDir on the fly to a directory outside of the site root. It also fails if the distDir can't be found from the. Cons: if the publish dir isn't a sibling of the Next config then this fails.If the user sets the publish dir, we might assume that the is in its parent directory.next, except with Nx, which rewrites it on the fly unless it has been changed by the user to something else, in which case it's left alone. By default this is out, and is where we move the files from distDir. The base dir, which is currently where we assume is, and where we run the build command.The exception is with Nx, which I'll cover more below. In most cases we can find this out from the config at 1. ![]() Currently the plugin assumes this is cwd(): i.e. When building a Next site, the build plugin needs to know two things: ![]() This is a particular problem for Nx sites, as they have no way of running commands from the app directory. This also doesn't work for monorepos that need commands to be run from the root. The workaround of prepending cd the/site/root before the build command does not currently work for Next sites, because build plugins always run from the base directory, meaning the plugin can't find all the Next files. This is because of the way Netlify handles monorepos. It either needs to be self-contained, or it needs to be in a yarn workspace. This means that it needs a package.json that installs all dependencies. Currently we can only handle monorepos if the Next site root directory (that contains ) can be set as base in the netlify.toml or UI.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |