Skip to content

chore: ignore npm tooling artifacts in .gitignore#118

Open
dfcoffin wants to merge 1 commit into
mainfrom
chore/gitignore-and-tooling
Open

chore: ignore npm tooling artifacts in .gitignore#118
dfcoffin wants to merge 1 commit into
mainfrom
chore/gitignore-and-tooling

Conversation

@dfcoffin
Copy link
Copy Markdown
Contributor

Summary

Adds node_modules/, package.json, and package-lock.json to .gitignore.
These artifacts appear when running npm-based developer tooling locally (schema
generators, linters, JSON schema previewers, etc.) and aren’t part of this
project’s Maven-based build.

Rationale

Without these patterns in .gitignore, any contributor who runs an npm-based script in the repo root has to manually exclude the resulting artifacts from every commit, or risks accidentally including a multi-megabyte node_modules/ directory in a PR. Adding the patterns once eliminates that friction and prevents the most common accidental-commit failure mode for npm tooling.

Scope

Three new entries in .gitignore only. No build configuration changes, no
behavioral changes, no impact on tracked files (none of these paths are
currently tracked in the repo).

Test plan

  • .gitignore parses correctly
  • After change, locally running npm install produces node_modules/ that does not appear in git status.
  • CI checks pass (Build and Test, Security Scan, PR Validation)

dfcoffin added a commit that referenced this pull request May 21, 2026
Replace ResponseEntity<StreamingResponseBody> with ResponseEntity<byte[]>
across the 9 controllers added by #116 (26 endpoints total), and drop
the corresponding asyncDispatch/MvcResult/request().asyncStarted()
plumbing from 30 MockMvc test methods.

Root cause of the flake: StreamingResponseBody worker threads raced with
the test thread on MockHttpServletResponse's LinkedCaseInsensitiveMap
when Spring Security's OnCommittedResponseWrapper triggered
HeaderWriterFilter.writeHeaders -> setHeader from the worker thread.
Surfaced by PR #118 CI as MeterReadingControllerTest
.shouldReturn200WhenExists ConcurrentModificationException.

The existing StreamingResponseBody pattern was fake streaming: JAXB
marshalled the full payload to byte[] before the worker thread ran,
so no real streaming benefit is lost. ESPI Sandbox response sizes
don't warrant streaming; production utility implementations of
/Subscription/* and /Batch/Bulk/* that need true streaming should
use StAX XMLStreamWriter + a JPA cursor (per issue #119 plan).

Verified: 90 tests, 0 failures, 0 errors across 3 consecutive clean
runs (mvn test -pl openespi-datacustodian).

Refs #119 (Phase 1)

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
@dfcoffin
Copy link
Copy Markdown
Contributor Author

Closing to retrigger CI now that the #120 de-stream fix has landed on main. Reopening immediately.

@dfcoffin dfcoffin closed this May 21, 2026
@dfcoffin
Copy link
Copy Markdown
Contributor Author

Reopened. Latest CI run should be unaffected by the MeterReadingControllerTest CME flake that #120 fixed.

@dfcoffin dfcoffin reopened this May 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant