Possibility of using package-lock instead of a touch-file for npm install conditions

[thismat]

Hey,

First off, thanks for the fantastic resource! Been using tailwind with blazor for over a year now and went to upgrade to tailwind 3, figured I'd look at if anyone came up with better integration and tooling, this is exactly what I needed to renovate and update my projects a bit.

One thing I found when I was combining information from a lot of different sources into one smooth process (sorry, I am going to try to find references to it, but it's been over a year since I setup my project and I forgot to take notes), is triggering the npm install off package-lock.json being watched for changes instead of a touch file.

    <Target Name="NpmInstall"
            Inputs="$(MSBuildThisFileDirectory)package-lock.json"
            Outputs="$(BaseIntermediateOutputPath)package-lock.json">

            <Message Importance="high" Text="Running npm install..." />

            <Exec Command="npm install" WorkingDirectory="$(MSBuildThisFileDirectory)" />

            <Copy SourceFiles="$(MSBuildThisFileDirectory)package-lock.json"
                  DestinationFolder="$(BaseIntermediateOutputPath)"
                  SkipUnchangedFiles="true" />

            <Message Importance="high" Text="npm install completed" />
    </Target>

Any reason this isn't a viable candidate? Maybe it isn't as smooth as using the touch file since you're depending on copying files, but the package-lock file changing is a pretty solid indicator of when a new npm install would need to take place if it hadn't already.

[McNerdius]

Glad the site has been helpful ! And thanks for giving me cause to take a look at this issue. Turns out the inconsistency i was seeing wasn't due to the Targets logic but: A) using the wrong path for "Inputs" (package.json) in some places and B) my brain sometimes going "why is the install target running?" whenever i see "tailwind build target running..." even though they're two separate targets.

tailblazor.dev's current build Target from tailwindcss.targets, relevant to this conversation (snipping the npm -v bit):

<Target Name="npm install" BeforeTargets="tailwind build" Inputs="./package.json" Outputs="./node_modules/.install-stamp">
    <Exec Command="npm install" />
    <Touch Files="./node_modules/.install-stamp" AlwaysCreate="true" />
</Target>

Regarding usage of package.json vs package-lock.json as the Target's Inputs: I find myself editing package.json manually rather than using npm CLI sometimes out of laziness. Delete a line from the dependencies array, change 3.0.0 to 3.0.8, that kind of thing. Maybe not a good idea, but using package.json as Inputs means dotnet build will keep things in sync even if i do mess about "manually".

Regarding touch files:

Unless i'm mistaken, the only thing that matters about the Inputs and Outputs are the files' timestamps. Copying package-lock.json to $(BaseIntermediateOutputPath) and doing a <Touch Files="./$(BaseIntermediateOutputPath)package-lock.json"/> would function the same. If "Inputs" is newer than "Outputs", regardless of filename/content, the incremental build happens.

Poking around a bit i noticed a ./node_modules/.package-lock.json file, documented here. So it seems npm install is doing that bit of the job for us as well.

I've changed my local "npm install" target to use it, as follows (again excluding the npm -v check):

<Target Name="npm install" BeforeTargets="tailwind build" Inputs="./package.json" Outputs="./node_modules/.package-lock.json">
    <Message Text="npm install target running..." Importance="high"></Message>
    <Exec Command="npm install" />
    <Message Text="npm install target finished !" Importance="high"></Message>
</Target>

Comparing the timestamp of my possibly-manually-edited package.json to that of npm install's Hidden Lockfile output.

I'll use this for a while and see how it goes. (Note to self: if all goes well, watch scripts must wait on hidden lockfile creation rather than prior .install-stamp)

Let me know if i've missed something !

---

Incremental build docs: https://docs.microsoft.com/en-us/visualstudio/msbuild/how-to-build-incrementally

[thismat]

Oh! That hidden package-lock.json file is a really nice find. I will be changing mine as well, no more copying a file around.

Comparing the package to the package-lock makes a lot of sense. I wonder if it's possible the mtime of the two files could render false positives? Testing will bring that to light relatively quickly though I'd imagine.

Thanks for all the hard work and detailed reply!

[McNerdius]

I've merged a new tailwindcss.targets and updated the description at https://www.tailblazor.dev/build#targets based on this discussion.

So far:

Regarding the npm install Target, the only significant difference from the original from StackOverflow is that it's taking advantage of npm's hidden lockfile rather than managing .install-stamp.

Other changes from my original .targets file: PascalCase naming of Targets; Message before and after both Targets; hide npm --version output as it is incidental/irrelevant.

---

A couple things i haven't squeezed into the text (yet?):

• Q: Why use the hidden lockfile as Outputs rather than the "normal" lockfile ?
  A: The hidden lockfile won't exist on a freshly cloned repo, ensuring an initial run of NpmInstallCheck. I touch on this under the dotnet watch section.

• I'm (still) using relative paths rather than MSBuild properties. Probably bad practice but MSBuild properties hurt my eyeballs sometimes :) I'll revisit this when i update TailBlazor-Templates' .targets files: the tailblazor-full template's .targets resides in a (RCL) subfolder, hence the relative paths are different.