Nx Office Hours | Angular 11, Nx 11, and Upgrading Your Workspace | Monday, November 16, 2020

we're live hey everyone welcome to nx office hours i'm here my name's zach i'm a engineer at narwhal we've got with us today uh jason jean who is uh an amazing engineer uh jason do you want to tell everyone about yourself and uh your role on nx yeah my name is jason i've been working on nx for probably two years plus something like that um and yeah nowadays i do a lot of the like core work so like anything with the affected and project graph and all that stuff and then i also help other people that work on nx so acting more of a lead for other features but yeah that's about it awesome we're super excited to have you on jason and uh great to see everyone in chat b-man nice to see you there and adam from normal a bunch of other folks i'm not familiar with yet but um looking forward to meeting y'all and uh having this time with you uh so uh just going through our agenda real quick uh we wanted to start off by doing uh in preparation for you know angular 11 uh just dropped last week uh nx 10.4 uh was released i believe earlier today and um we we have some plans to drop nx11 uh in the next couple weeks or so uh so we're just going to do a quick live demo uh to share how we would go about migrating and to do that let me start by um sharing in the chat this is a link to our live uh or to to our official examples there we go if if anyone wants to follow along we're just gonna uh i've just uh get cloned this repo and we're going to run nx migrate on this so hopefully everyone can see that all right i'll make it a little bigger just in case um so the command we're just going to run is we're going to run nx migrate and pass in our version right now we're on 10.3 uh so i'm going to run this command to specify that we are uh targeting version 10.4 and this may take a little bit uh because we're going to go through and uh fetch all the new packages and um and bring those down so so while we're doing this um uh there is the angular 11 uh official article i'll throw into the chat now uh so this was uh released by the on the angular blog it talks a little bit about all this stuff that 11 does one of the most interesting things uh for me was the hot module reloading uh which i think we'll talk about in a question coming up but yeah um jason i believe you're working on right now an article explaining uh some of the nx 10.4 release improvements do you want to talk about those a little bit while we're waiting on this yeah we had a few features that we wanted to add to uh 10.4 before 11 so uh one of those is going to be updates to incremental building uh we have some updates for building with angular making that faster um the other update is we're starting to like refine our eslint configs so if you're using react or using um eslint we're going to start using overrides for things so there's a lot of different kind of files in the workspace that might want a different set of rules um so we're going to be starting to moving that over to using overrides if you migrate to 10.4 you might see that in your projects um and the the cool thing about it is that we've also introduced eslint presets for nx so before um if you're on 10.3 and you're generating react projects each of those comes with like a 200 flying eslint rc that json and that's a lot of code to be adding to a workspace when we could be publishing a config or a preset that handles that and that will actually be automatically migrated for you so you'll probably see that 200 some odd lines are removed from your like every eslint rc.json and it'll add in the the preset as well so this is going to be more maintainable for the index workspaces and also it's going to make it easier for us to kind of modify our recommendations over time those are the the two biggest changes and uh yeah cool i think um are we going to have an article about all the 10.4 um changes um i think sometime this week yeah i'm working on an article that'll explain more of it just keep uh stay tuned for that awesome thanks jason uh so our our initial migrate command ran successfully if you all can see my terminal here we have some feedback here saying our packets.json has upgraded as well as some migrations json has been generated and if we look at the version control we can see those two files here on the side so our migrations file i believe is showing us um uh so so this is this is essentially like a list of things that we're going to want to run after installing our new dependencies is that right jason yeah so annex migrate doesn't install stuff for you there's just a lot of caveats and like how you install stuff it might be from like a local artifactory right um so we stay out of that realm but what we do do is that we tell you what packages you might want to install so if you look at the package json changes that you have right now you will see that we upgraded at normal angular and occasionally this will include non narwhal stuff as well so like if cyprus or prettier needs to be updated well then there you go like prettier also has changed there but you'll notice that we don't actually install them so if you do like mpm ls prettier right now or yeah you could do that as well there you go okay so it'll still be on two zero five right it'll tell you it's invalid because we haven't installed it yet so from here you're going to want to install the packages right so i would just run yarn to do this because this uh yeah oh wait we have the packing sauce and we have a yarn oh and we have a yarn lock we don't have that packet spot cool so i'm going to run yarn to install the dependencies and i believe when we ran the nx it told us these would be our next steps so makes make sure our practice json changes make sense and then run npm installer yarn that's going to get our new dependencies installed into our node modules then we have this next step of running nx migrate and that is going to run migrations based on our migrations.json file cool yeah so the other thing that nx migrate did the first time is that it gave you a file that lists out the different migrations in order to run those migrations you need to be on that version right so you need to install them first and then you can run the migrations make sense so now that i've installed them by running yarn i can paste in the command that told me to run before which is pretty much going to run the migrations based off of the json file json file not json then um yeah that worked pretty quickly yeah so this is super quick at this point because everything's already installed and now it's running some migrations so it did very little npm installing here if at all a relevant question i just noticed and i'll be trying to watch chat a little closer here but uh before a phil sorry if i mispronounced your name jorge apologies uh should we commit uh my grayson.json to the repo um so migration.json migrations.json is there in your repo that you could commit it so if we were working in a large project and let's say we don't want to migrate um the eslint configs yet right we could run all the migrations for that remove them from our migrations on json and then committed to the repo in that state while still working on the the other migrations there's a lot of different things that you can do with the migrations.json um you you could also like remove some migrations from here to not run them when you run the migrations so yeah be clever i guess but in general if you've run on the migrations if everything is being done all at once then no i would not commit migrations.json and it will get reset the next time you run nx migrate without the run migrations fly so it'll get reset there cool and um another relevant question i just want to kind of cherry pick while we're here how granular to our operations our migrates need to be going from nx 10.1 to 11. should we should we migrate to each minor version or should we uh we just go to 11. um i'm assuming you could just go right to 11 but jason maybe you know better than me yeah you should be able to go straight to 11. um i've done migrations where it was like people are on version one of nx and i moved over to like version six like at a conference um so it works very well if you do run into issues though then it might be better for you to do it incrementally so you should be able to do it step by step as well but i am fairly confident that you should be able to just go to the latest at any time oh wow so so if we're if if we were on angular 9 for example could we just one run migrate in one step for a 211 potentially i i can't promise anything but yes i'm fairly confident that it will bring you all the way to 11. if your workspace is fairly like i guess the the way that we recommend it if you've made a lot of changes to your workspace then there might be times where we've overlooked a customization to a workspace and it doesn't work as intended and then um you should do it step by step and see if you can figure out those issues cool thanks jason um sweet well um i think that's pretty much all we have to show in terms of our demonstration um right now obviously i think for uh when we go to actually go to nx11 um i i think that may be more interesting but i think the the the basic uh just of what we're trying to accomplish here i think is pretty well demonstrated by this so if when nx 11 comes you probably just want to do a similar procedure as what we just did nx migrate and pass in 11 and go from there so cool um uh we'll i'm noticing there's some questions coming in live um i'm going to uh prioritize some of the questions we have gotten beforehand so we can try to get as many as possible so i'll i'll hit those first and if we have more time we'll try to pick out some of these questions we're getting live um but let me start with um this question from a user called as574 paste it here in the chat um so the question was will fast refresh be supported anytime soon for react and or angular and or view and so a fast refresh for people that may not be familiar and i wasn't until i got this question googled around a little bit so this is this is a term being used kind of in the react community for some tools they have called uh i think it's called react fast refresh that is essentially doing um uh hot module loading on um on their uh serving of a uh react project while you're in development mode um so so the answer for this is angular 11 is going to support hot modular reloading nx just uses angular builders behind the scenes so essentially when nx11 comes out with support for angular 11 we'll be able to support uh fast refreshing or hot module reloading uh for angular um for react i believe we don't have any immediate plans to support fast refresh but we'll revisit this after nx11 is released and jason um uh correct me if i'm misspeaking on any of these things and uh since the question mentions it also there is um for review we actually don't have any um first party support for view plugins but we do have a a list of nx community plugins and you can see the entire list here and there's uh one specifically for vue that i've used before that i believe is quite good um and i'll link the github to this as well so if anyone's interested you can go in and install the the nx community view plug-in and um you'll be able to get some view builders and view schematics that will help you on your way in view i'm not sure i'm not not familiar enough with you to know if uh hot modular reloading is supported or not but if it is the the community plug-in would likely support that and you could probably ask for that there so yeah um seconds half of the question from as574 uh let me paste it in here uh was will react native be supported and if so when this would be an amazing ad as we have both a react app web app and a react native app that needs to share components types of functions and etc and so for this uh jack from narwhal actually just released a blog article on this very topic how we're introducing react native support so uh feel free to check that out make sure you plan for it and all that good stuff and um yeah he did a demo for us last week and it was it was pretty cool to see so very excited about that um moving moving along we have a question from abel henson who asked let me paste this in for us to read through it he wants to know if there's any possibility to add an nx cli add to nxti a tool to build a full application using do you know js with some of its web frameworks like oak and lf maybe you already working on that so um they're as of right now we don't have any official uh dino uh plug-ins uh or community plug-ins at the moment um jason and i had actually talked about this a couple weeks back because i was very interested in dino i think you know super cool um but the the one of the interesting things about dino is obviously the the import syntax is different right so um the that kind of poses a problem in terms of having our typescript files kind of being able to be and run in nodeland and in dinoland where the imports won't work across the two and obviously any any kind of node dependencies is going to kind of make some of those things unusable but um i i think jason you can inform me if i'm wrong here there's there's i think there's a package called dinofy that will do some things to resolve the issues with imports so there's some potential here to kind of have you know support inside of an nx workspace i don't think that's something we've explored too deeply but in theory it it would be possible to have some dino support inside of nx so yeah i haven't tried it personally um i can't wait to try it and i'm just busy but if there are issues using d nullified that you think we should know about um then create an issue in the nx repo and we might take a look uh yeah i think that is probably the route will go to my knowledge the only other way to do it is like releasing a whole separate other version that's dino um compatible and don't quite want to do that i also think that for dino you can import from like github as well so like you could even just point to like the master branch but i think in order for that to work does it have to be right you know so dina will just take a url probably doesn't so so potentially you can just point to files that way yeah so but i don't think it'll work with nx because our code is not dino compatible anywho don't take my word for it i haven't tried it um so try it for yourself see what the like the available kind of like migration or the um compatibility layers options are and hopefully nx works with them if it doesn't then let us know to get up issue and we can take a look cool uh we're gonna jump into the next question here this question's from uh jorge who we heard from earlier when we're doing our demo um let's see if this piece is right this um maybe it didn't come in great okay it broke it up into several things through the street art so apologies for that but the the question was around patterns to integrate the router when it comes to navigation through different libraries when within a library i would like to navigate relative to the entry corner on the nav on the library module so that the library navigation implementation does not change regardless of who loads it but it could be loaded by the application or another library now things get worse when trying to use the secondary router outlets especially if they are not authorized so um i i believe um we're talking about angular here i'm assuming so um when it when it comes to this uh using router links um you can already do sort of relative paths um for for for links to um things inside the library so that that may be something to look at there uh jason and i actually talked about this a little bit beforehand there's a project we're working on um that kind of talks about uh modules uh are loading mobiles and um and routing to different things that that we're seeing some similar problems i think to what you're describing here for a uh did you want to to add anything to what we've already talked about jason i feel like you had mentioned something before um no i think that pretty much covers it i don't think there's anything like annex specific about this i would say that like a pattern that you could try using is if the the module or the library itself brings like a little widget kind of thing and like has a link on it um and it also includes the route then you should use a relative link there to make sure that it gets set up correctly um but i'm not exactly too sure about the code so yeah and no worries that just i wasn't sure how it was going to face that either so it worked out just fine so cool uh moving on to the next question this one's from uh nate kidwell uh the question was uh timeline for nx10 or sorry got nx10 next.js 10 support um so i we we looked this up um in the in the few minutes before we went live here and it looks like nxra supports next js 10. um which may be getting into what we're what we're qualifying as support here but um yeah the the the dependencies are pointing at next version 10. so um that's what we came up for this um uh nate if you're if you have any more questions feel free to paste them in here and we'll try to address those as well um moving on to the next part of nate's question let me put this in here uh there's a missing sjs flag on nexus so the sjs flag i believe is supposed to to mark that um that that will be using uh javascript files as opposed to typescript files which is irrelevant because next.js consumes js is this an oversight or an inconvenience um anything to add on this one jason the js flag will be coming for next js it's um a little bit of an oversight or a little bit more of it like we're phasing in the the js flag um but yes we have a pr that's open right now it's being worked on by a external contributor named martin so yeah that is going to add the js flag i believe for next as well as probably express and node and all those things as well so yeah it's a little bit of an oversight or we're getting to it kind of thing so expect it soon awesome and the last part of nate's question is there an equivalent to learner's canary flag or is this underway so so the dash canary flag as i found out earlier today is an option that learner supports on their published command that when publishing to npm it can kind of mark it as a canary uh version or canary release to kind of um mark it as something that's experimental uh to and kind of like warn people maybe uh stay with the stable ones but um the the answer to this is nx is purposely unopinionated uh when it comes to versioning and releases um if you're looking for some plugins to support um sort of a first winning strategy or something that could be useful for doing something like a canary release you can check out our community plugins uh the one named nxpm um is uh actually run by b-man who i saw in the comments up here earlier so b-man thanks again for your help with that but um this is a solution to nx that supports semantic versioning i believe other uh versioning solutions as well i think there may be some other community uh plugins that attempt to do different uh similar things for for versioning as well so yeah um that's that's the answer uh for you there and again feel free to feel free to follow up on this if you're if you're watching now um moving on to our next question that we had that came in before the show um this one came in anonymously uh so the question was what about the basil support uh we had announced a while ago and uh victor actually uh victor satkin our great leader the premier comrade uh created a blog post on this uh recently so um i've linked that in the chat here so you can go check it out basically the answer is we had originally intended to reach for bazel support as a way of doing computation caching and distributed uh cached builds um and when yeah we've got some we've got some love coming in from b-man so right back after you sir and nate uh thanks for thanks for the questions dude but um yeah going back to the question of basil support um because of some because of some friction on basil and just some of the difficulty it would take to support a basal solution we ended up introducing computational caching and distributed building ourselves so computation caching comes as part of nx when you install it we also have our nx cloud solution i'll paste the link to that here just nx dot app which it will will take care of the distributed cache buildings which will you know speed up your your builds but without having to use bazel so i believe we still want to have some solutions for integrating with bazel in the future uh but for now if if you want to take advantage of nx's native computation caching or our distributed cloud builds you can also take a look into the solutions we offer for now and of course victor offers some more explanation in the blog if you want to take a look at that um so yeah uh and thanks uh for devon showing up i believe devon runs and extends and uh some cool ionic stuff there so thanks y'all for showing up and uh for making annex cool with your community uh contributions so yeah uh we've got one more anonymous question and then i'll we'll see if we can grab some from the uh from the live questions i saw up above um this one's a longer one too so let's see how it comes in from stream yard okay um so the question is what are future plans for solution style ts config files angular cli 10.1 reverted solution style config introduces by 10 because of several problems that need to be fixed by the typescript team nx still uses solution style configuration which leads to errors for example generating angular libs with english a lot greater than 10.1 because of the missing tsconfig.base.json how will nx11 handle this situation so uh jason we talked about this uh a little bit uh beforehand um so i i believe we should still be able to use the solution configs is that correct yeah um we recommend that you use solution ts configs they solve a real problem and um it's much better for separating your typings for like tests and your runtime code and all that so first off i recommend that you use them now i know that um the angular cli starting from 10.1 rolled back their change for the solution ts configs and in theory like there is no strict requirement on solution style ts configs for nx to work um nx works with typescript mostly and no matter how you do typescript you should be able to use nx um that said there probably are issues that arose from when we kind of during the nx 10 release we were looking at how they think did things in angular 10 or angular cli 10 and i don't think we've fully gone through and um revisited the the way that they do things in 10.1 um so in theory it should work if you run into any issues please open a github issue and try to be as descriptive as you can because um you know i definitely mentioned that you're using not solution style to use configs and then like mentioned when you run into the issue so that we know we're currently in a state where we're trying to support both like the solutions.ts config and the non-solution style ts config um and when generating code we might make certain assumptions that we shouldn't be making so loosely so open issues if you find anything and we'll be taking a look awesome thanks and and thanks for every anyone uh who will go through and open up those issues for us we we appreciate it and uh especially if you add the details like jesus is talking about to make our lives easier much appreciated um i'm going through some of our earlier live questions let's start maybe with this one i think we may have asked this one already so how granular oh yes we did we did answer this one i'm sorry i think i put the wrong one okay so this is the one i meant to click uh so the question is hey guys how do i migrate major versions and update angular to the latest version in this major i think when i tried to migrate eight to nine angular didn't upgrade to the latest v9 so um i believe inside of our migration scripts we're going to put you on the angular version that makes sense for the version of nx you're migrating to um i believe past that so if there's the miners for example doesn't quite match up i believe you can just run like um just update manually update the packets json yourself to target the relevant version um does anything about that seem problematic to you jason or is that is that essentially what you'd tell as advice as well yeah um i do recall like when testing nx version nine uh angular did get upgraded so unless there was an error i'm not sure why it's not being upgraded for you version nine is when ivy came in so that could be a big part of it there's a lot of migrations there that were fairly picky about the the code but um yeah that that is a particularly tough upgrade for the runtime code but i'm not exactly sure why it didn't work cool um well uh moving on to our next question here um the question is trying to build a pet project using node.js and express my project will contain a couple cli scripts what's a good way to include those cli scripts to uh to build the app so there is um in in nx we're kind of following angular's lead using builders where we run scripts um so so a potential solution would could be here to write your own builder i don't know if i recommend that one necessarily i know in some of our internal projects we also use um nps uh node package scripts um which is a decent solution for us for some of our things it seems to [Music] uh maybe be a little bit easier than writing your own builder um so that that could be another solution to look into jason do you have any uh advice for this question yeah i think um what you might be looking to do is include this in your builder's config so like in workspace.json you can use a builder called at normal slash workspace colon run commands um so this is a builder that's really meant for just like i want to run something in the terminal right that's like what i want to do when i call and next build or something like that right um so you can use that builder and call the cli that you want to use um this is kind of like the the kind of like downs in the middle like i just want to run the shell script when i do this command so try that one out um that being said like if you want more like um better like dev ergonomics of like passing in different options and stuff like that then as i can mention that you can build your own builder um but if this works for you then i i wouldn't go any further i 100 agree on that i've run into issues where i was trying to do something fancy and write my own builder and i jason actually was trying to help me on this and we came down to why in the world would we try to rewrite a builder when we could just use some of the ones that nx has already so and that turned out to be the best solution so that was great very helpful jason um i i put uh i'm showing right now the link you can click on it in chat too uh the this will take you to the uh documentation for run commands that jason was talking about here and you can also take a look around um for some of the other tools that you can use to do similar things so yeah um let's see if i can find another question here um another one from jorge here i don't know if we uh specifically addressed this but um maybe we touched on it a little bit so the migration command will this also upgrade angular version and the the answer i think is yes right jason this will this will just put us onto the angular version that we recommend for the nx version you're migrating to yep um nx migrates all the dependencies that we add per se so if you generate a new workspace with angular we're the ones that had angular so we take that under the the responsibility of our next to migrate right so if you the idea with nx is that if you migrate nx you would also migrate any dependencies that nx was the one that brought in if you're bringing in things like angular material or i don't know like other angular things right then those might not be upgraded so you'll have to upgrade those by yourself but thankfully with the the angular migration stuff hopefully they have migration migrations as well and you could use um like nx migrate to do that as well so if you do like annex migrate at angular slash angular material then you would be able to use annex migrate for that as well but you have to explicitly say that you're migrating a different package cool thanks jason um next question we have uh nick roberts who knows i ran ng update earlier today and was met with cannot find module trying to find tslib.js i upgraded last week so i'm not sure if i bought something um so yeah um jason do you wanna do you wanna um feel this i'm trying to think maybe um a good a good sibling question to this is maybe should we run ng update uh in an nx workspace or so we just let nx migrate to do work for us when when migrating they are both supposed to work um we both use the same migrations like schema behind the scenes if you're running into an issue there um the first thing i would do is actually go into the community slack and see if anyone can like debug with you people there are extremely nice and help everyone debug and if you can find like a concrete way to reproduce it then please open an issue in nx hopefully with like a reproduction repo migrations in particular are very hard to kind of create issues for because they're like oh i have this super obscure project that's private and you can't see it but it fails um but i i do think that the community slack is a great solution for this if you kind of want to talk to someone about it that might have already run the migration maybe ran into a similar issue and figured out how to solve it so yeah go there and if there's an issue then please do open additional github but the reason why i don't suggest doing that like right out of the box then um yeah like try try to do it with or try to get help i guess cool yeah i've thrown the link for the community slack here in chat if you wanna if you wanna go and join there um let's see if i can find any other questions um uh another one here will nx11 need to do anything related to module federation or is it fully up to angular um so so nx is really just using um angular builders behind the scenes um so i imagine that this would just be all an angular support i'm not super familiar with macho federation though so there may be something missing there uh jason are you uh this seems like something you know about uh anything further to add here yeah so um the other thing i'll add is that community member uh the name escapes me manfred medford stayer is uh currently looking into model module federation for angular so i bet his builders might also help you there so it's um i think it's like angular build plus or ng build plus um yeah ngx build plus so i imagine those will help you there and manfred would also be a great person to reach out to about module federation but in terms of the if angular decides to support module federation which i think is included in the version 11 of things which as an opt-in then annex would inherit those as well since we use the angular filters for angular apps cool thanks uh next question can we opt in webpack five in nx jason i'll let you take this one yeah uh same deal with angular 11 i think you'll want to upgrade to angular 11 so uh first so that means like upgrading to nx11 um but then i think their recommendation is to use yarn and then to set the resolutions um when we look into nx11 maybe in like nx 11.1 or something we might even switch to webpack five like explicitly uh the nice thing about builders is that like webpack 5 is like behind the scenes like you don't really need to know that we use webpack um so we could upgrade it behind the scenes and you don't have to do much of anything more kind of like advanced usages of webpack 5 such as module federation and stuff like that might take a little bit more work but yeah hopefully in the the near future either has part of the 11.0 release or the 11. one two three four um we will have support for webpack five but westpac five is very exciting so we'll probably look into that soon again for for angular if you're looking for angular um we use the builder so you can refer to the version 11 release blog post where they recommend to use the resolutions out of curiosity jason what makes webpack 5 so exciting for you uh there's a lot of like optimizations for like making it run faster i think caching is a huge part of it but then also the module federation and a lot of stuff the webpack team is just killing it lately so looking forward to all those changes but those are the two things that i'll call out awesome so we jump into our next question uh npm 7.0 introduces workspaces is nx going to support that soon i'm i'm actually not sure about this uh jason was this on your radar at all yeah i looked in so npm workspaces is more of like a yarn workspaces thing all the package managers they seem to want to like have functionality that allows you to have multiple package jsons and manage them so it becomes like a package manager manager um so nx recommends that you use one single package.json for your whole workspace and this like uh it simplifies a lot of things so like if you're migrating versions of angular like you only migrate on one version and then everything gets migrated over so that's definitely the way that we recommend you do it but it is possible to do multiple package jsons in an nx workspace and i think npm workspaces should work fine for that they should be fairly independent of each other so yeah give it a try if you run into any issues for whatever reason again follow like file an issue and we'll be glad to take a look but to be honest i don't know if like the the standard nx workspace is going to benefit much from mpm7 workspaces cool sounds good um devin shoemaker asks have we ever thought about supporting a single app workspace nx tooling could still be valuable for orcs that don't need mono repos maybe a schematic that could migrate them to a mono repo later so devin this is something that's near to my heart because often if i ever want to write a script i'll actually just like way over kill it and create a new edx workspace just for that because it seems to be uh possibly the easiest way of configuring typescript and all that stuff to just get a simple way to run a script so i do this quite a bit i don't know if we have any official support for for what you recommend like a schematic to migrate them into a targeted monorepo later that could be pretty cool but um i don't know if we've we have any plans to do this that seems like it would be a difficult schematic to write um has this ever come up before i don't think it has come up i'll say yet um so we did release the uh make angular cli faster i think was the command so that moves over like an angular cli workspace which is generally more for single applications or like one application right while keeping the file structure which i think is the um the main concern here so we do have logic when you're like before we used to just migrate the people to the the mono repro structure we used to take an angular cli workspace and kind of say that hey your one app is actually now one of many apps that you're about to create um but i don't that portion of the logic is not separated into a separate schematic so we don't currently have it but it should be fairly easy for us to do it but no one has that on their in their pipeline yet so if you want to help us out and do that portion you're more than more than happy to accept the pr for that awesome very cool uh community uh the community has been a huge part of the next and it is it's one of the things i like most about doing the show is to see just all the all the cool things that are coming out of this and sort of the passion uh other people see so yeah um if anyone wants to pr that that would be really awesome so yeah uh let's see i'm just gonna see if i can find any more questions i think we kind of caught up to where i had been in the chat history uh we got some praise for uh run commands thanks be man and and devin uh there and let's see um so i i think nick this was a follow-up to when we were addressing your question sorry i missed it when we were asking it live i think uh everything work seems to work i just want to make sure i didn't break any nx functionality um no i don't think if you're if you're just uh touching your angular dependencies i don't think there's anything there that would break something in x um nothing i'm aware of at least so um b-man mentions i keep suggesting folks not to update angular before annex updates is there an official recommendation on this um i see you nodding jason i think that means uh we i i asked victor this question earlier today in our internal slack i think you would probably make it work if you're updating angular 2 11 before nx11 comes out but i think the official recommendation is essentially just to wait until an x11 is out and um to upgrade angular as part of your migration and that way you can do it all in one swoop and uh like we said it should be out in the next couple of weeks or so so hopefully there won't be much of a delay there so yeah anything to add to that jason yeah if you can wait let nx do it for you um yeah so like we write the schematics or we run we write the migration to migrate angular for you if you really really want to do it um or like i think this applies to if you're behind on angular versions and you really want to just like migrate to the latest runtime without redoing your whole build or whatever um then you could try and do angular separately but i do think it's easier to move the tooling first than move the angular version right so like in theory you could move to an x11 and like you would still build angular 10 but that's not the question here like they're fairly independent um i i do think there is like a compatibility buffer so i think angular cli in particular will support like maybe the last version or two versions of angular don't take my word for that there confirm it for yourself but it's supposed to at least take the it's supposed to be able to build the latest or the last version so yeah cool um a a similar question here from danny mcgee if i'm not very angular in my nx workspace are there any compelling reasons to update to nx11 yeah so we haven't really talked about what's in nx11 yet so um i mean one of those things is going to be an angular upgrade but there's a lot of things coming in nx11 that you're going to want um i mean in general i recommend that you stay up to date on nx a lot of the core changes that might come in for 11 would make nx faster stuff like that um i mean react in particular is experiencing like a lot of new features and improvements so i don't want to assume anything but if you're not running angular i assume you're running react or node and so like i would definitely there's like probably an equal amount of improvements that are going to be seen there if not more um so yes definitely um all nx workspaces should move to the latest version but uh yeah i think that answers the question cool um so christian jazz when will nx11 be released do you want to upgrade to angular 11 as soon as possible to benefit from some new features so um i had seen i think some stuff on our nx channel saying that um well i think victor had said we'd have it in the next couple weeks on friday is that timetable changed at all jason are you aware uh sometime in the next few weeks yeah we we do try to stick as close to the angular releases as possible um however for this one we are a little bit more ambitious so we have a few more things that we want to get into the nx11 release so stay tuned next few weeks uh i mean there's thanksgiving coming up so a lot of people will be off but um yeah next few weeks i'm not gonna promise a date because we'll just be late and then people will be upset but we are working on it for sure we're not gonna be behind that that much cool um a couple more questions here how to share core components code with other organizations work within your monorepo without sharing other parts of your code um so this um this is a question i think we've we've had on previous episodes a couple times are questions similar to this um so so in addition to um you know having a monorepo approach you can also obviously still do things like just importing other packages so publishing uh other packages inside of your organization so you can consume it inside of your monorail um that will still work obviously um it might be better to actually get the code inside your mono repo to to benefit from some of the uh the the benefits you get from having all your code inside of the one repo so um so yeah uh and do you have anything to add there jason no i think you covered it cool um any thoughts on supporting stacklets that would be kind of cool i i'd honestly never thought about that before um but yeah yeah um for stack blitz we've sponsored them for a long time so we definitely like what stack blitz is doing um there is a version like last time i checked when we um met up with the stack blitz team at ngconf 2019. um before the whole pandemic stuff um there was a beta of full stack for stack blitz and i believe what happens there is that they have a kind of like a server-side rebel for use or like a server-side terminal for you to use and that would in fact support an x now i think you do have to pay for that but um yeah that is something that you can look into uh i'm not fully versed on it i think it should have been released like you know close to a year ago so give it a shot i think they did a talk on edgy conf about it if you can find that you might be able to find more information about it but right now it's not uh it's not i don't have it off inside my head so it might already be supported that's what i'm saying yeah gotcha cool uh got a question here from sergio trying to hit these last couple questions while we still have time uh is there any tip on how you can optimize test run when you have lots of libs and spec files um so this is a question we've kind of hit on before the potentially one of the the best optimizations i think you could run this maybe having something on um something like uh distributed uh builds which um you know we you have nx cloud solution available to you obviously you're still going to have to run your tests at least once but the idea is uh your your history is shared across all the machines that happen to to have run any tests so if your ci's already running these tests for you against the same code it will it will benefit from it having been run before on someone else's machine or that could help with your ci cd times i don't know if there's there's anything really beyond that that i would uh have good confidence confidence to recommend uh jason do you have any thoughts definitely check out nxcloud that's going to help you with rebuild times a lot but then also look at your dependency graph so if you run nxt step graph you'll get a visual kind of picture of how your workspace looks and if you notice that like there's there's going to be certain libraries that you know have like lots of tests and if there are ways to avoid that in your change path then that is going to benefit you but without like knowing your workspace i'm not exactly sure if there is an issue there or if there's something that you can do to better optimize that it does sound like you already have lots of libs but i do think like lots of having more libs is going to help you shave off a lot of that of that time and then um yeah there might be better improvements that we can do in the future for optimizing this but i don't have any updates on that at this time well and just um i i kind of uh assumed this was already known but just making sure you're running it with nx affected when you're running your tests as well to make sure you don't you don't run tests against things that aren't affected by your pr's um yeah so yeah sorry go ahead that's probably the first thing that you should do there's many different things so um the first thing you want to do is make sure you're only running those that are affected then also make sure you're running things that are affected in parallel on one machine um if that's like and then the next thing you should probably do is integrate annex cloud so that things are cached the last thing that you might want to do is like spread them across multiple different machines that last part is probably the hardest of the few it's not that hard we have material on how to do it but in terms of like the difficulty for what you're trying to achieve that's probably the last on your your list so yeah sorry i already assumed that you were doing all of that if not definitely check that out very cool all right we're we're just about out of time i'll try to make sure we uh we gather up these these questions and uh address them on our next episode if there's any i miss i think we may have gotten them all but um yeah i'll i'll do a once through after this is over i'm putting a link in here for any future questions too we have this our google form now we'll try to be using this as our main tool for gathering questions going forward we've already plugged the community slack a little bit as well as an x cloud that's come up several times uh make sure if you're if you're here please like and subscribe because we are subject to the youtube algorithm too and uh it would help us out um i also have uh link here to our nx repo on github uh stars are appreciated um so one last plug to get in before we wrap up to uh check out uh our twitter handle uh nx dev tools uh there's a link there uh follow that one and you feel free to tweet questions at that as we'll be fielding them um so uh yeah that's pretty much all we've got thanks everyone for coming by jason thank you so much for uh for stopping by for office hours this was this is lots of fun thank you sir it was a pleasure awesome thank you everyone see y'all

Channel: Nrwl - Narwhal Technologies Inc.

Views: 2,894

Rating: 4.9411764 out of 5

Keywords:

Id: W7b55ANw0fI

Length: 58min 48sec (3528 seconds)

Published: Mon Nov 16 2020