NPM Build Errors - first time back to project - New set-up on Windows machine

[SeanPGit]

TL;DR
I get NPM Build errors "second" time building a new "env" OR maybe only when adding ENABLE_WIFI to the build?

Back Story
In anticipation of the Mezmeriser board arriving (still no signs of it yet!)...

I started to play with my existing boards / latest builds my very ageing PC!
A very old (10+Years!) Dell XPS 8300, i5 core, 24GB RAM, TBs of spinning rust, no GPU (on-board Intel video; the original fan seized years ago, never replaced!).

I have a couple of M5 Stick CPlus (v1.1) - one flashed a long time ago with a "Demo" build I'd "butchered" with too many effects, from a build on a different (work) laptop.
I also have an M5 Stack Core (basic): Note turns out NOT a "Core2" as I thought it was! (You can probably see where this is going!).
One(!) strip of LEDs!

Gory Details
I set-up the build environment for the First time on this "new" PC, thus:

1. Read the README.MD (I promise - ;-))
2. Installed VS Code.
3. Installed Platform IO.
4. Installed git and git add-ins to VS-Code (it did this when I prompted to sync the repository).
5. Installed Node.js (windows installer from https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) to get the npm tool.
6. Resynched my fork of https://github.com/SeanPGit/NightDriverStrip
7. Started Building...

Not wishing to touch my "working" (024 install) on the M5 Stick+, I targeted the build towards my M5 Stack Core.
Started building [env:demo]. No Threadrippers here - so this is taking a very long time!...

After reading the related discussion #433, realised I could select the COM Port and Build from the PlatformUI Status Line (thanks @rbergen !) ... I realised I probably should be building for a better target platform!

Abandoned build and went looking for something more appropriate...

I duly noted that there was no [env:m5stackdemo] for M5 Stack Core to go with [env:m5demo] and [env:m5plusdemo] for M5 Stick / Plus, respectively...
I found the existing [dev_m5stack] so added [env:m5stackdemo] to go with it, and started the build...

Whilst building... I then noticed that dev_ has board = m5stack-core2 and included in lib-deps = https://github.com/m5stack/M5Core2.git...
To which I went reading to refresh my memory of features of the board... and realised mine was NOT a "Core2"! 🤦‍♂️

Hence I changed my repo thus:

• Added [dev_m5stack-core]
• Changed [dev_m5stack] to [dev_m5stack-core2] (Naughty boy! but I couldn't see it was used / referenced anywhere!?)
• Added [env:m5stackdemo] and [env:m5stackc2demo] to reference the respective boards.
• KEPT -DM5STACKCORE2=1 for "Core2" and added -DM5STACKCORE=1 for my "Core Basic" board.
• Changes to global.h and a few other places to adapt to my plain old M5STACKCORE vs M5STACKCORE2.

Surprisingly this seemed to build and get pushed out OK.
Working "Rainbow" effect on my little string and nicely updating display! 😁

Looking through the code - I was intrigued that the buttons on the device didn't appear to do anything and found the code for switching effects and info screens - tied to TOGGLE_BUTTON_1 and TOGGLE_BUTTON_2 so assigned appropriately for "my" build.

(Side note: I'm convinced some "Board features" should be tied to the BOARD not the EFFECT "Project" BUILD (LATERN, UMBERELLA etc. ?
That said - if a "board feature" also introduces undesirable things like "waiting for a button press" when the device is now hidden in the eaves and only expecting "Wifi"... Hey ho! In which case - perhaps Dave should document "which board" !?)

Anyhow - now I get NMP errors in the build! (There - we got there in the end!) - (I include a "Success" above just to show that was the case!
`================================================================================================= [SUCCESS] Took 523.24 seconds =================================================================================================
Environment Status Duration

---

m5stackdemo SUCCESS 00:08:43.237
================================================================================================== 1 succeeded in 00:08:43.237 ================================================================================================== * Terminal will be reused by tasks, press any key to close it.

• Executing task: C:\Users\Sean.platformio\penv\Scripts\platformio.exe run --target upload --environment m5stackdemo --upload-port COM3

Processing m5stackdemo (board: m5stack-core-esp32; platform: platformio/espressif32@^6.3.0; framework: arduino)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via -v, --verbose option
npm ERR! code EPERM
npm ERR! syscall rmdir
npm ERR! path E:\Source\seanp-nightdriverstrip\NightDriverStrip\site\node_modules\webpack\lib\stats
npm ERR! errno -4048
npm ERR! Error: EPERM: operation not permitted, rmdir 'E:\Source\seanp-nightdriverstrip\NightDriverStrip\site\node_modules\webpack\lib\stats'
npm ERR! [Error: EPERM: operation not permitted, rmdir 'E:\Source\seanp-nightdriverstrip\NightDriverStrip\site\node_modules\webpack\lib\stats'] {
npm ERR! errno: -4048,
npm ERR! code: 'EPERM',
npm ERR! syscall: 'rmdir',
npm ERR! path: 'E:\Source\seanp-nightdriverstrip\NightDriverStrip\site\node_modules\webpack\lib\stats'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It's possible that the file was already in use (by a text editor or antivirus),
npm ERR! or that you lack permissions to access it.
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

npm ERR! A complete log of this run can be found in: C:\Users\Sean\AppData\Local\npm-cache_logs\2023-09-27T13_10_18_316Z-debug-0.log
CalledProcessError: Command 'cd site && npm ci' returned non-zero exit status 4294963248.:
File "C:\Users\Sean.platformio\penv\Lib\site-packages\platformio\builder\main.py", line 167:
env.SConscript(env.GetExtraScripts("pre"), exports="env")
File "C:\Users\Sean.platformio\packages\tool-scons\scons-local-4.5.2\SCons\Script\SConscript.py", line 598:
return _SConscript(self.fs, *files, **subst_kw)
File "C:\Users\Sean.platformio\packages\tool-scons\scons-local-4.5.2\SCons\Script\SConscript.py", line 285:
exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals)
File "E:\Source\seanp-nightdriverstrip\NightDriverStrip\tools\bake_site.py", line 55:
subprocess.check_call('cd site && npm ci', shell=True, stdout=subprocess.DEVNULL)
File "C:\Users\Sean.platformio\python3\Lib\subprocess.py", line 413:
raise CalledProcessError(retcode, cmd)
========================================================================================= [FAILED] Took 87.05 seconds =========================================================================================

Environment Status Duration

---

m5stackdemo FAILED 00:01:27.054
==================================================================================== 1 failed, 0 succeeded in 00:01:27.054 ====================================================================================
`

So - is this a "platform" (Unix v Windows) expectation in NPM and only occurs because of an npm "cleanup" on the second build pass?

[robertlipe]

I think the intersection of npm and windows is a very new one, like in the last week or so. Rant: Those error messages violate almost every rule of good taste. I'd try to find what it couldnt rmdir and to manually help it. Maybe it's stupidly failing to remove something not there or maybe it created something and didn't give itself permission to clobber it. If you don't want to tackle it head-on, npm was only really recently introduced. You could likely git time travel a week or two ago to before npm landed... but I think the project itself is going to have to have a solution for whatever's ailing your work tree. Oh, and. I agree on both our naming conventions (which I probably will help do something about) and that our build times are uncharacteristically bad. Readme claims 30nsefind builds, but my M1 (not a thread ripper, but not a slouch) can take 30 seconds before it starts the first compile sometimes. We're both overbuilding (touching remote control. H shouldn't rebuild the world) and. Somehow not treating scins very well because python takes more cpu than the summation of all the cc1plus calls. But none of this is related to your issue...

…

On Wed, Sep 27, 2023, 10:55 AM Sean Pearce ***@***.***> wrote: *TL;DR* I get NPM Build errors "second" time building a new "env" OR maybe only when adding ENABLE_WIFI to the build? *Back Story* In anticipation of the Mezmeriser board arriving (still no signs of it yet!)... I started to play with my existing boards / latest builds my *very* ageing PC! A very old (10+Years!) Dell XPS 8300, i5 core, 24GB RAM, TBs of spinning rust, no GPU (on-board Intel video; the original fan seized years ago, never replaced!). I have a couple of M5 Stick CPlus (v1.1) - one flashed a long time ago with a "Demo" build I'd "butchered" with too many effects, from a build on a different (work) laptop. I also have an M5 Stack Core (basic): Note turns out NOT a "Core2" as I thought it was! (You can probably see where this is going!). One(!) strip of LEDs! *Gory Details* I set-up the build environment for the First time on this "new" PC, thus: 1. Read the README.MD (I promise - ;-)) 2. Installed VS Code. 3. Installed Platform IO. 4. Installed git and git add-ins to VS-Code (it did this when I prompted to sync the repository). 5. Installed Node.js (windows installer from https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) to get the npm tool. 6. Resynched my fork of https://github.com/SeanPGit/NightDriverStrip 7. Started Building... Not wishing to touch my "working" (024 install) on the M5 Stick+, I targeted the build towards my M5 Stack Core. Started building [env:demo]. No Threadrippers here - so this is taking a *very* long time!... After reading the related discussion #433 <#433>, realised I could select the COM Port and Build from the PlatformUI Status Line (thanks @rbergen <https://github.com/rbergen> !) ... I realised I probably should be building for a better target platform! Abandoned build and went looking for something more appropriate... I duly noted that there was no [env:m5stackdemo] for M5 Stack Core to go with [env:m5demo] and [env:m5plusdemo] for M5 Stick / Plus, respectively... I found the existing [dev_m5stack] so added [env:m5stackdemo] to go with it, and started the build... Whilst building... I then noticed that dev_ has board = m5stack-core2 and included in lib-deps = https://github.com/m5stack/M5Core2.git... To which I went reading to refresh my memory of features of the board... and realised mine was NOT a "Core*2*"! 🤦‍♂️ Hence I changed my repo thus: - Added [dev_m5stack-core] - Changed [dev_m5stack] to [dev_m5stack-core2] (Naughty boy! but I couldn't see it was used / referenced anywhere!?) - Added [env:m5stackdemo] and [env:m5stackc2demo] to reference the respective boards. - KEPT -DM5STACKCORE2=1 for "Core2" and added -DM5STACKCORE=1 for my "Core Basic" board. - Changes to global.h and a few other places to adapt to my plain old M5STACKCORE vs M5STACKCORE2. Surprisingly this seemed to build and get pushed out OK. Working "Rainbow" effect on my little string and nicely updating display! 😁 Looking through the code - I was intrigued that the buttons on the device didn't appear to do anything and found the code for switching effects and info screens - tied to TOGGLE_BUTTON_1 and TOGGLE_BUTTON_2 so assigned appropriately for "my" build. *(Side note: I'm convinced some "Board features" should be tied to the BOARD not the EFFECT "Project" BUILD (LATERN, UMBERELLA etc. ? That said - if a "board feature" also introduces undesirable things like "waiting for a button press" when the device is now hidden in the eaves and only expecting "Wifi"... Hey ho! In which case - perhaps Dave should document "which board" !?)* Anyhow - now I get NMP errors in the build! (There - we got there in the end!) - (I include a "Success" above just to show that was the case! `================================================================================================= [SUCCESS] Took 523.24 seconds ================================================================================================= Environment Status Duration ------------------------------ m5stackdemo SUCCESS 00:08:43.237 ================================================================================================== 1 succeeded in 00:08:43.237 ================================================================================================== * Terminal will be reused by tasks, press any key to close it. - Executing task: C:\Users\Sean.platformio\penv\Scripts\platformio.exe run --target upload --environment m5stackdemo --upload-port COM3 Processing m5stackdemo (board: m5stack-core-esp32; platform: platformio/espressif32@^6.3.0; framework: arduino) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via -v, --verbose option npm ERR! code EPERM npm ERR! syscall rmdir npm ERR! path E:\Source\seanp-nightdriverstrip\NightDriverStrip\site\node_modules\webpack\lib\stats npm ERR! errno -4048 npm ERR! Error: EPERM: operation not permitted, rmdir 'E:\Source\seanp-nightdriverstrip\NightDriverStrip\site\node_modules\webpack\lib\stats' npm ERR! [Error: EPERM: operation not permitted, rmdir 'E:\Source\seanp-nightdriverstrip\NightDriverStrip\site\node_modules\webpack\lib\stats'] { npm ERR! errno: -4048, npm ERR! code: 'EPERM', npm ERR! syscall: 'rmdir', npm ERR! path: 'E:\Source\seanp-nightdriverstrip\NightDriverStrip\site\node_modules\webpack\lib\stats' npm ERR! } npm ERR! npm ERR! The operation was rejected by your operating system. npm ERR! It's possible that the file was already in use (by a text editor or antivirus), npm ERR! or that you lack permissions to access it. npm ERR! npm ERR! If you believe this might be a permissions issue, please double-check the npm ERR! permissions of the file and its containing directories, or try running npm ERR! the command again as root/Administrator. npm ERR! A complete log of this run can be found in: C:\Users\Sean\AppData\Local\npm-cache_logs\2023-09-27T13_10_18_316Z-debug-0.log CalledProcessError: Command 'cd site && npm ci' returned non-zero exit status 4294963248.: File "C:\Users\Sean.platformio\penv\Lib\site-packages\platformio\builder\main.py", line 167: env.SConscript(env.GetExtraScripts("pre"), exports="env") File "C:\Users\Sean.platformio\packages\tool-scons\scons-local-4.5.2\SCons\Script\SConscript.py", line 598: return _SConscript(self.fs, *files, **subst_kw) File "C:\Users\Sean.platformio\packages\tool-scons\scons-local-4.5.2\SCons\Script\SConscript.py", line 285: exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals) File "E:\Source\seanp-nightdriverstrip\NightDriverStrip\tools\bake_site.py", line 55: subprocess.check_call('cd site && npm ci', shell=True, stdout=subprocess.DEVNULL) File "C:\Users\Sean.platformio\python3\Lib\subprocess.py", line 413: raise CalledProcessError(retcode, cmd) ========================================================================================= [FAILED] Took 87.05 seconds ========================================================================================= Environment Status Duration ------------------------------ m5stackdemo FAILED 00:01:27.054 ==================================================================================== 1 failed, 0 succeeded in 00:01:27.054 ==================================================================================== ` So - is this a "platform" (Unix v Windows) expectation in NPM and only occurs because of an npm "cleanup" on the second build pass? — Reply to this email directly, view it on GitHub <#447>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD3ZHR3OT5KQIWMSE7SLX4REAVANCNFSM6AAAAAA5JS4TGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[SeanPGit]

Thanks @robertlipe I was aware of the recent addition. Strange and varying results though - some builds fail some don't!

I have noticed that node stuff happens early in the build with no real indication it's going on - just a long, ominous, pause after:
Processing m5stackdemo (board: m5stack-core-esp32; platform: platformio/espressif32@^6.3.0; framework: arduino) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via -v, --verbose option

and Before:
> app@0.1.0 build

[rbergen]

I apologize for "kicking in an open door" as the Dutch expression goes, but it seems to be a permission problem. Have you tried removing the "E:\Source\seanp-nightdriverstrip\NightDriverStrip\site\node_modules\webpack\lib\stats" by hand under your regular user account to see if that works? If not, then it's not that strange that NPM can't do it either.

(I notice the logging mentions two different drives/partitions. That doesn't have to be a problem in itself, but it does make things "slightly less straightforward".)

[SeanPGit]

Thanks - yes I did think of manually assisting it... I will try that.
Interesting development - I kicked off another build / upload and it completed this time! (in fact twice!)

(Actually I was a little convinced in my cycle of getting the platform thing working - it had worked / failed / worked but wasn't sure - because of the platform switching that went on!).

The drives - well the "tools" (VS Code, PlatformIO, Node.js etc.) are installed on C:, and my user's "home" directory appears to be there too (I thought I'd made inroads to shifting that to E:\ some time ago - but Windows is a strange beast to coax into doing that wholesale!?). The Git repository synched to E:... It would be nice if the "Build" was contained within the source tree, not bits in my "Home" directory (per the Pio & node stuff).

[SeanPGit]

Confirmed "not a permission problem" per-se; I can remove rafts of that "site\node_modules" stuff by hand (Windoze Explorer).

Also - I'm still not fully confirmed (or denied) the behaviour that triggers it. I'm now convinced if hits pretty "randomly" and "random" groups of files each time - when it occurs!
Can do builds that work* then suddenly next build getting the NPM error(s)...
Pretty sure it always occurs with the "clean" operations ... And I also tried & failed to switch platforms to one of my M5 Stick+ using the standard env for those... Getting NPM errors after the system finally resolved the dependencies...
Switching back to (my) M5StackCore env - they then persist (as does the COM4 that then got selected for the "Stick" cannot switch back to the COM3 the Stack presents as!).
If / when I find time - on Sunday - I'll try to "cleanup" and conduct more scientific approaches to nail down the pattern or - as suggested elsewhere - revert to pre-npm builds for now! (that will be a new experience - time-travel with Git / VS Code! :) ).

[robertlipe]

That's freakishly consistent with my "my system wanders around in weeds before even invoking it's first compiler for tens of seconds" observation. I don't know where that "Verbose mode can be invoked by invoking verbose mode verbosely, yo!" is coming from, but that's new, too. Remember, Sean, that nothing in computers is truly random. Figuring out the cause and effect can make us crazy (I've had bugs manifest exactly every 497 days, bug when a branch in a delay slot was taken to an address that was a cache miss on an address that ended in "c", corruption if more than 5 bits on the bus changed in consecutive cycles, etc.) but we just cannot generation randomness in a world ruled by logic. Finding that pattern is now your challenge. :-) I hadn't thought to blame npm. I've had sub-awesome build times well before that, though. I'll admit I did take a few weeks off doing any "real" work off in the project, so I don't have a total recall of commit and effect. I tried running a build-buddy a few days ago and it was just agonizing. It's Very Rare to spin up the fans on my MBP and after it actually panicked the system (which happens almost never on MacOS) I didn't even restart it, figuring that two builds ought to be enough for anyone. :-)

…

On Wed, Sep 27, 2023 at 12:30 PM Sean Pearce ***@***.***> wrote: Thanks @robertlipe <https://github.com/robertlipe> I was aware of the recent addition. Strange and varying results though - some builds fail some don't! I have noticed that node stuff happens early in the build with no real indication it's going on - just a long, ominous, pause after: Processing m5stackdemo (board: m5stack-core-esp32; platform: platformio/espressif32@^6.3.0; framework: arduino) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via -v, --verbose option and Before: > ***@***.*** build — Reply to this email directly, view it on GitHub <#447 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34W35V6PIH7WDWANIDX4RPEFANCNFSM6AAAAAA5JS4TGA> . You are receiving this because you were mentioned.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/447/comments/7126089 @github.com>

[SeanPGit]

@robertlipe "Remember, Sean, that nothing in computers is truly random.". I know. 😋
As is my day job. "Somethings stopped working". "OK, Q: what have you changed?" "A:Nothing!". Me "I don't believe you (more diplomatic) with a systematic series of questions" and "provide the evidence...") Raise tickets anyway, to the best of my ability and start second guessing / analysing the given evidence (Knowing, knowing)...
Usually followed by "Oh yes, we found out somebody "restored the backup" or "decided X was better over Y"... 🤣)
I'm also lazy; read only the first paragraph... respond/react early (despite giving multiple paragraph answers I know nobody reads! Hence "TL;DR" or "Executive Summary"). etc. 😬
Twice in (ahem!) 40 years has it been "our fault" (when I believed the word of "our" people... for THEM to admit the error!)... 🤨

Howevet! Slight embarrasment! 😳 The "pattern" for the the NPM "challenge" is me not seeing the screen and hitting "clean" instead of "upload"... 😮🤪 Never the less - some problem to investigate here!

Still - my "builds" seem OK - even with the "fixes" I've made for my (not a Core2!) Core board...
But I may take a closer look at "why" - try the manual stuff etc. - but there "so little" I don't know about how this build environment works - how the npm is kicked off etc. etc. (Whethert it's a "deep" part of something bought in - or "within" our our source code etc.?) ("Where's the make file!? 😎😋)

P.S. 2.5 sheets to the wind and post pub-quiz - so some of above probably does not make much sense.
P.P.S. To the @rx7 guy: I'm taking my RX-8 to a track-day late tomorrow - so also won't spend too much more time on "this" project until Sunday! :D
P.P.P.S Sorry for wasting bandwidth due to my slight laziness!

[robertlipe]

But I may take a closer look at "why" - try the manual stuff etc. - but there "so little" I don't know about how this build environment works - how the npm is kicked off etc. etc. (Whethert it's a "deep" part of something bought in - or "within" our our source code etc.?)

I wrote a reasonable description recently of how the C++ source gets mutated by platformio.ini and globals.h if you need to look for that, but I stay out of site/

("Where's the make file!? 😎😋)

I actually put some effort into capturing the build command issued by Platformio to get a compilation database and then reversing that into CMake so that I could get a build that's fast. Once I accepted I was going to have to tackle issues like "compile everything and maybe the linker can throw it out" and "globals.h" IS the build system, I fled. In another window right now, I have some changes in the oven to make the project less likely to recompile the world when you touch anything. Enough of us caring about pet peeves (that actually matter) is what it takes. Build times and modularity are amongst mine. You might find useful another doc I wrote in the discussion area on the zen of command line builds and getting the debug chatter out of the device. I find "type r to do that again" much more automatable than pawing at a GUI for code. Message ID:

…

<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/447/comments/7127888 @github.com>

[SeanPGit]

Thanks & I'll take a peek. Glad it's not "just" my ageing rust bucket of a PC, performance wise!

This dinosaur is still struggling to understand Git (plenty of prior RCS, PVCS, Perforce, but I stopped programming in anger, perhaps ~20 years ago!), and all this CD/CI malarkey; the auto-dependency building which aught to be a good thing...

Many miles away from my "Save 3 copies on tape, compile(assemble)-in-memory-over-the-source-code-and-run-it days on the ZX Spectrum; which did end up with Assemble-and-squirt-over-the-[homebrew-parallel]cable-to-machine-running-[homebrew]monitor (in real-time as the machine code was emitted from said assembler - often whilst still RUNNNG the game under test == 'very careful' changes to code!) we later used on our 8- and 16-bit dev kits!
That is fairly closely akin to "this" stuff which is probably what attracts me. 🙃

[KeiranHines]

@SeanPGit if you can are you able to provide your node and npm versions node -v and npm -v?
I will have limited access to my Windows machine over the next 2 weeks, however I will attempt to replicate the issue on my Linux machine.

One cause, although I don't know how practical it would be be if something was accessing the node_modules director while the build was taking place. Say VS-code doing a file scan, re-indexing, or similar.

One difference from npm ci to npm install is that ci will remove the node_modules directory if it exists, basically doing a clean install.

npm ci was used over npm install in bake_site to make the build more repeatable and to not update the package-lock file every time someone built. An alternative solution would be to update the use of npm ci in back_site to be npm install --save false which will prevent updating the package lock file, but will also prevent cleaning the node_modules directory each build which should prevent any issue.

[SeanPGit]

Thanks @KeiranHines - Sorry for late answer - been away for weekend.

C:\Users\Sean>node -v
v18.18.0
C:\Users\Sean>npm -v
9.8.1

One cause, although I don't know how practical it would be be if something was accessing the node_modules director while the build was taking place. Say VS-code doing a file scan, re-indexing, or similar.
Could be - you mean like this:

[KeiranHines]

No worries Sean, I have been travelling myself. That could do it if platform io is indexing whilst the build is tried. Platform io would be scanning the node modules whilst the build script attempts to delete them.

[robertlipe]

Re: build times.
If you just blindly stab at the GUI IDE to build (I did) you want to be sure you're selecting the specific project you're building. The pertinent setting seems to be at the bottom of the screen that's over to the right. It's invisible on a reasonable sized laptop screen and there's no hint there's horizontal overflow.

I naively started a build in the GUI on a new-ish tree and flipped to another desktop to do other things. Im on an M1 MBP so it's not an enterprise server, but it's not a slouch. Eventually, I closed all the tabs I was reading and popped back to that:

================================= [SUCCESS] Took 187.80 seconds =================================

Environment               Status    Duration
------------------------  --------  ------------
demo                      SUCCESS   00:02:10.450
m5demo                    SUCCESS   00:02:37.027
m5plusdemo                SUCCESS   00:02:52.239
heltecdemo                SUCCESS   00:02:42.421
heltecv2demo              SUCCESS   00:03:44.290
heltecv3demo              SUCCESS   00:03:27.532
lilygo-tdisplay-s3-demo   SUCCESS   00:03:32.090
ledstrip                  SUCCESS   00:03:05.568
ledstrip_feather          SUCCESS   00:02:39.306
ledstrip_feather_hexagon  SUCCESS   00:03:25.062
ledstrip_feather_wrover   SUCCESS   00:03:10.173
ledstriplite              SUCCESS   00:02:53.259
ledstrip_pico             SUCCESS   00:03:32.840
spectrum                  SUCCESS   00:03:49.605
spectrum_elecrow          SUCCESS   00:04:56.853
spectrumstack             SUCCESS   00:03:30.949
spectrumlite              SUCCESS   00:03:32.141
spectrum_wrover_kit       SUCCESS   00:02:54.842
mesmerizer                SUCCESS   00:03:04.104
mesmerizer_lolin          SUCCESS   00:03:05.977
laserline                 SUCCESS   00:03:05.125
lantern                   SUCCESS   00:03:08.019
chieftain                 SUCCESS   00:03:00.975
umbrella                  SUCCESS   00:02:52.211
generic                   SUCCESS   00:02:54.634
panlee                    SUCCESS   00:02:44.887
ttgo                      SUCCESS   00:02:40.117
xmastrees                 SUCCESS   00:03:06.599
insulators                SUCCESS   00:03:22.680
magicmirror               SUCCESS   00:03:11.406
atomlight                 SUCCESS   00:02:39.762
fanset                    SUCCESS   00:03:06.089
cube                      SUCCESS   00:03:07.797
================================= 33 succeeded in 01:43:47.029 =================================

A build time of nearly 2 hours wasn't particularly kind to battery, but it was nearly 2 hours. Unfortunately, since PIO (VSCode?) insists on downloading yet another copy of every library to build everything - whether that project uses the library or not - the object code caching can't work sensibly because the "same" files have different paths. Each of the 33 trees gets a unique build of everything.

If we made the git project pull in the libraries into the source tree, we'd get better visibility of the libraries (you wouldn't have to dig around in .pio/builddeps) and I think we'd get better locality and reusability between project. My 54GB (!) .pio directory says we have room for less duplication. (NightdriverLED is "only" ~50 source files + a bunch of libraries...)

So if your build times are really bad, double check that you're building ONLY what you think you're building. Your i5 might not be blazing, but if you're building ONE project, the time should still be pretty small - on the order o low number of individual minutes Even with duplicates, most of your source tree will be coming from RAM and not spinning rust most of the time. Look over the shoulder of what you're actually building.

[SeanPGit]

Thanks @robertlipe - yes I did cotton onto that after first couple of (overnight here!) builds; perhaps "to many aborts" in the background does not help matters.

Agreed that perhaps something needs to be looked into to add optimisation to the dependencies between each build; a lot is hidden away behind PIO magic from my eyes...

I'll try to find time to do a more scientific exercise for the NPM error itself; and see that I can get reliable builds against both my "newly introduced" M5 Stack Core and existing M5Stick+ builds - without them clashing in some way (they shouldn't if the builds ARE segregated?)!

[brentrockwood]

Hi folks. New here. I do Node and React development. Maybe try doing your npm install just at a plain command line and see what happens. Take PIO and VSCode out of the equation. You are welcome to reach out if you need help.

[rbergen]

@SeanPGit I just merged #465 that was opened by @KeiranHines. That should fix the issue you were experiencing. Can you confirm if this is the case, and if so close this discussion?

Thank you!

[SeanPGit]

Thanks all! Was a little surprise to see the fix related to my report; great work all round. I'll see what difference it makes for me! :)

[SeanPGit]

@rbergen pretty good news. Did some re-syncing of my project(s) last night... And managed to switch between the M5 StickC+ and my M5 Stack Core builds, on my dinosaur machine... Observations:

1. Overall everything - especially rebuilds seems much faster ("only" 10 minutes ;-)... And re-builds much quicker (albeit without changes).
2. No NPM clashes detected. Have not tried a "Clean-up" then build yet.
3. Kicked off a "full build - all environments" last night - it was still running at 0730 when I left for work; I can check the results tonight.

Given I've not seen any NPM clashes / errors - I think it's safe to say that is "fixed"?

[rbergen]

Thanks for the update, that's good news indeed. After my previous comment I actually ran into the issue you were experiencing on a machine I had not yet applied #465 to, and haven't seen it reoccur after I did. So, I'll close this as resolved.