By elephant I mean: big heavy thing. Here some thoughts on the fatso node_modules folder which for this little project holds 89.9 MB and 10,559 files. But these are just thoughts and not solutions. I'm trying to figure out what is best to do. If you add this sort of thing to source control or add it to a Visual Studio 2017 RC solution you will see the proverbial spinner spinning a little bit. In the case of including in it a .csproj file, you will quickly find that you can't compile as there will be one hundred and one things (well, twenty-four without hyperbole) nested in third party gunk the TypeScript compiler hates. Putting <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> inside the first <PropertyGroup> in the .csproj file will stop TypeScript compilation when you build. This means no TypeScript compilation from within Visual Studio, but maybe that's not the end of the world. I don't see why I can't build (and thus sanity check) TypeScript at the command line. Why does everything work there and not in Visual Studio? Well, I suppose that is another puzzle. I guess it's trendy to have an Angular 2 frontend that one just works with in Visual Studio Code that merely talks to C# through REST calls effectively putting the C# and the TypeScript in two entirely different applications. And yet, that begs the question: "What if you want to mix Angular 2 into a traditional MVC app?" With regards to source control, it's gonna be painful to tuck node_modules away if it actually gets updates regularly. I guess you would start out hoping that such isn't the case. Not keeping a copy in source control could lead to some terrible, terrible surprises when you pull the code two years later and try to rehydrate the folder only to find that newer versions of libraries introduce devastating changes. I don't know what to do about any of this.
It's a gamble either way, right?
No comments:
Post a Comment