This removes in-browser compilation support from Stencil. Doing so
involves a number of changes, including:

- removing the rollup plugin which polyfills node.js built-in modules
  (fs, path, etc) for use in the browser
- deleting the code for the polyfills themselves (found in
  src/compiler/sys/modules)
- miscellaneous refactors related to tests for browser vs node
  environment as well as testing

There will be more follow-up work to fully address this stuff, but this
makes the minimal change to remove browser support for Stencil.

This removes one of the concrete instances of the `Logger` interface that we currently maintain, the `console-logger`. This is the logger instance that was used when Stencil was run in-browser. After #4317 we no longer need this, so we can delete some code! 🎉

The change basically 1) removes that code and then 2) replaces all calls to `createLogger` with calls to `createNodeLogger`.

* chore(ci): enable ci for v4 dev (#4433)

this commit enables browserstack for the v4 development branch

* chore(compiler): remove dynamicImportShim (#4420)

* remove dynamicImportShim

* remove `dynamicImportShim` references from some tests

* add field removal to breaking changes

* chore(compiler): remove safari10 extras flag (#4421)

* remove safari10 extras flag

* remove `safari10` references in some tests

* add field removal to breaking changes

* chore(compiler/runtime): remove CSS var shim & patchEsm() (#4419)

* remove CSS var shim & patchEsm

* remove `cssVarShim` references from some tests

* remove some errant code

* add field removal to breaking changes

* fix build error

* 🎬 v4.0.0-beta.0

* chore(compiler/runtime): remove shadow dom shim (#4440)

* chore(ci): enable ci for v4 dev (#4433)

this commit enables browserstack for the v4 development branch

* chore(compiler): remove dynamicImportShim (#4420)

* remove dynamicImportShim

* remove `dynamicImportShim` references from some tests

* add field removal to breaking changes

* chore(compiler): remove safari10 extras flag (#4421)

* remove safari10 extras flag

* remove `safari10` references in some tests

* add field removal to breaking changes

* chore(compiler/runtime): remove CSS var shim & patchEsm() (#4419)

* remove CSS var shim & patchEsm

* remove `cssVarShim` references from some tests

* remove some errant code

* add field removal to breaking changes

* fix build error

* 🎬 v4.0.0-beta.0

* remove public-facing shadowDomShim option

* missed one

* update todo comments

---------

Co-authored-by: Ryan Waskiewicz <ryanwaskiewicz@gmail.com>

* 🐐 v4.0.0-beta.1

* refactor(many): remove in-browser compilation support (#4317)

This removes in-browser compilation support from Stencil. Doing so
involves a number of changes, including:

- removing the rollup plugin which polyfills node.js built-in modules
  (fs, path, etc) for use in the browser
- deleting the code for the polyfills themselves (found in
  src/compiler/sys/modules)
- miscellaneous refactors related to tests for browser vs node
  environment as well as testing

There will be more follow-up work to fully address this stuff, but this
makes the minimal change to remove browser support for Stencil.

* 👻 v4.0.0-beta.2

* chore(props): removal of deprecated connect and context APIs (#4437)

BREAKING CHANGE: this removes the connect and context APIs which have been deprecated since Stencil v1

This means that the following code will no longer work.

```ts
@prop({ context: 'config' }) config: Config;
@prop({ connect: 'ion-menu-controller' }) lazyMenuCtrl: Lazy<MenuController>;
```

* chore(deps): remove unused hash.js dependency

* chore(deps): remove unused path-browserify dependency

* chore(deps): remove unused process dependency

* chore(deps): remove unused assert dependency

* remove node 14 from CI matrices

* bump min node versions across core

* update `rmDir`/`rmDirSync` to `rm`/`rmSync`

This commit updates some calls to Node fs module functions to follow recommended approaches after deprecations were added for `{ recursive: true }` on `rmDir` and `rmDirSync`

* make node versions consistent

* bump @types/node & lockfile versions

---------

Co-authored-by: Ryan Waskiewicz <ryanwaskiewicz@gmail.com>
Co-authored-by: Alice <alice.writes.wrongs@gmail.com>
Co-authored-by: Jess <jess@jessicasachs.io>

This removes in-browser compilation support from Stencil. Doing so
involves a number of changes, including:

- removing the rollup plugin which polyfills node.js built-in modules
  (fs, path, etc) for use in the browser
- deleting the code for the polyfills themselves (found in
  src/compiler/sys/modules)
- miscellaneous refactors related to tests for browser vs node
  environment as well as testing

There will be more follow-up work to fully address this stuff, but this
makes the minimal change to remove browser support for Stencil.

This removes one of the concrete instances of the `Logger` interface that we currently maintain, the `console-logger`. This is the logger instance that was used when Stencil was run in-browser. After #4317 we no longer need this, so we can delete some code! 🎉

The change basically 1) removes that code and then 2) replaces all calls to `createLogger` with calls to `createNodeLogger`.

In #4317 as part of removing in-browser compilation support we removed
the polyfills for nodejs built-in modules like `path` which were
injected by Rollup during build-time. Although the _main_ purpose of
these polyfills was allowing Stencil to run in the browser in the case
of the `path` module there was also a secondary purpose which was
ensuring that paths were treated the same way across supported platforms
(posix + windows).

See, for instance, the following lines in the polyfill:

https://github.com/ionic-team/stencil/blob/b911f1986a0d583bd1e3cd42cbbca9b255c32f2d/src/compiler/sys/modules/path.ts#L35-L38

These functions basically wrapped the existing path implementation with
our `normalizePath` helper, which would ensure that the output paths
would be the same on both windows and posix systems (e.g. macOS and
linux).

When we merged #4317 an effort was made to add `normalizePath` around
the codebase where it was thought that various paths being calculated
needed to be platform-independent, however, a few locations were missed
(in particular, some paths output into typedefs, which would show up as
non-posix paths when building on windows).

To address the issue we introduce `relative` and `join` functions into
the existing path-related `utils` file (which is incidentally renamed)
which work similarly to how the patched functions in the old polyfill
did. Then several usage sites are changed to import those new utils
instead of the 'raw' functions from `path`. Together these changes
should ensure that Stencil's output is not platform-dependent.

See here for an issue reporting the problem: #4543

This removes the `IS_NODE_ENV` variable from our environment module
which previously was used to switch between browser-specific and
node-specific approaches to various things in the Stencil compilation
process.

Following the merge of #4317 we only support one runtime, node, for
compiling Stencil components, so we can assume that `IS_NODE_ENV` is
`true` and delete code accordingly.

This removes the `IS_NODE_ENV` variable from our environment module
which previously was used to switch between browser-specific and
node-specific approaches to various things in the Stencil compilation
process.

Following the merge of #4317 we only support one runtime, node, for
compiling Stencil components, so we can assume that `IS_NODE_ENV` is
`true` and delete code accordingly.

This removes the `IS_BROWSER_ENV` from our environment module.
Previously this was used to signal when Stencil was being used to
compile components in a browser environment.

After we removed support for that functionality in #4317 we don't need
the variable any longer, so we can assume that `IS_BROWSER_ENV` is
`false` and delete dead code accordingly.

This removes the `IS_BROWSER_ENV` from our environment module.
Previously this was used to signal when Stencil was being used to
compile components in a browser environment.

After we removed support for that functionality in #4317 we don't need
the variable any longer, so we can assume that `IS_BROWSER_ENV` is
`false` and delete dead code accordingly.

This removes the `IS_NODE_ENV` variable from our environment module
which previously was used to switch between browser-specific and
node-specific approaches to various things in the Stencil compilation
process.

Following the merge of #4317 we only support one runtime, node, for
compiling Stencil components, so we can assume that `IS_NODE_ENV` is
`true` and delete code accordingly.

This removes the `IS_BROWSER_ENV` from our environment module.
Previously this was used to signal when Stencil was being used to
compile components in a browser environment.

After we removed support for that functionality in #4317 we don't need
the variable any longer, so we can assume that `IS_BROWSER_ENV` is
`false` and delete dead code accordingly.

In #4317 as part of removing in-browser compilation support we removed
the polyfills for nodejs built-in modules like `path` which were
injected by Rollup during build-time. Although the _main_ purpose of
these polyfills was allowing Stencil to run in the browser in the case
of the `path` module there was also a secondary purpose which was
ensuring that paths were treated the same way across supported platforms
(posix + windows).

See, for instance, the following lines in the polyfill:

https://github.com/ionic-team/stencil/blob/b911f1986a0d583bd1e3cd42cbbca9b255c32f2d/src/compiler/sys/modules/path.ts#L35-L38

These functions basically wrapped the existing path implementation with
our `normalizePath` helper, which would ensure that the output paths
would be the same on both windows and posix systems (e.g. macOS and
linux).

When we merged #4317 an effort was made to add `normalizePath` around
the codebase where it was thought that various paths being calculated
needed to be platform-independent, however, a few locations were missed
(in particular, some paths output into typedefs, which would show up as
non-posix paths when building on windows).

To address the issue we introduce `relative` and `join` functions into
the existing path-related `utils` file (which is incidentally renamed)
which work similarly to how the patched functions in the old polyfill
did. Then several usage sites are changed to import those new utils
instead of the 'raw' functions from `path`. Together these changes
should ensure that Stencil's output is not platform-dependent.

See here for an issue reporting the problem: #4543

This removes the `IS_NODE_ENV` variable from our environment module
which previously was used to switch between browser-specific and
node-specific approaches to various things in the Stencil compilation
process.

Following the merge of #4317 we only support one runtime, node, for
compiling Stencil components, so we can assume that `IS_NODE_ENV` is
`true` and delete code accordingly.

This removes the `IS_BROWSER_ENV` from our environment module.
Previously this was used to signal when Stencil was being used to
compile components in a browser environment.

After we removed support for that functionality in #4317 we don't need
the variable any longer, so we can assume that `IS_BROWSER_ENV` is
`false` and delete dead code accordingly.

* refactor(environment): remove IS_NODE_ENV and delete dead code

This removes the `IS_NODE_ENV` variable from our environment module
which previously was used to switch between browser-specific and
node-specific approaches to various things in the Stencil compilation
process.

Following the merge of #4317 we only support one runtime, node, for
compiling Stencil components, so we can assume that `IS_NODE_ENV` is
`true` and delete code accordingly.

* refactor(environment): remove IS_BROWSER_ENV and delete dead code

This removes the `IS_BROWSER_ENV` from our environment module.
Previously this was used to signal when Stencil was being used to
compile components in a browser environment.

After we removed support for that functionality in #4317 we don't need
the variable any longer, so we can assume that `IS_BROWSER_ENV` is
`false` and delete dead code accordingly.

In #4317 as part of removing in-browser compilation support we removed
the polyfills for nodejs built-in modules like `path` which were
injected by Rollup during build-time. Although the _main_ purpose of
these polyfills was allowing Stencil to run in the browser in the case
of the `path` module there was also a secondary purpose which was
ensuring that paths were treated the same way across supported platforms
(posix + windows).

See, for instance, the following lines in the polyfill:

https://github.com/ionic-team/stencil/blob/b911f1986a0d583bd1e3cd42cbbca9b255c32f2d/src/compiler/sys/modules/path.ts#L35-L38

These functions basically wrapped the existing path implementation with
our `normalizePath` helper, which would ensure that the output paths
would be the same on both windows and posix systems (e.g. macOS and
linux).

When we merged #4317 an effort was made to add `normalizePath` around
the codebase where it was thought that various paths being calculated
needed to be platform-independent, however, a few locations were missed
(in particular, some paths output into typedefs, which would show up as
non-posix paths when building on windows).

To address the issue we introduce `relative` and `join` functions into
the existing path-related `utils` file (which is incidentally renamed)
which work similarly to how the patched functions in the old polyfill
did. Then several usage sites are changed to import those new utils
instead of the 'raw' functions from `path`. Together these changes
should ensure that Stencil's output is not platform-dependent.

See here for an issue reporting the problem: #4543

In #4317 as part of removing in-browser compilation support we removed
the polyfills for nodejs built-in modules like `path` which were
injected by Rollup during build-time. Although the _main_ purpose of
these polyfills was allowing Stencil to run in the browser in the case
of the `path` module there was also a secondary purpose which was
ensuring that paths were treated the same way across supported platforms
(posix + windows).

See, for instance, the following lines in the polyfill:

https://github.com/ionic-team/stencil/blob/b911f1986a0d583bd1e3cd42cbbca9b255c32f2d/src/compiler/sys/modules/path.ts#L35-L38

These functions basically wrapped the existing path implementation with
our `normalizePath` helper, which would ensure that the output paths
would be the same on both windows and posix systems (e.g. macOS and
linux).

When we merged #4317 an effort was made to add `normalizePath` around
the codebase where it was thought that various paths being calculated
needed to be platform-independent, however, a few locations were missed
(in particular, some paths output into typedefs, which would show up as
non-posix paths when building on windows).

To address the issue we introduce `relative` and `join` functions into
the existing path-related `utils` file (which is incidentally renamed)
which work similarly to how the patched functions in the old polyfill
did. Then several usage sites are changed to import those new utils
instead of the 'raw' functions from `path`. Together these changes
should ensure that Stencil's output is not platform-dependent.

See here for an issue reporting the problem: #4543

in #4317 (b042d8b), a polyfill for node's `path.join` was [removed](https://github.com/ionic-team/stencil/pull/4317/files#diff-734f69edf83052dfd5ce6df10429550680537c6da66ef9b7cfbda11efdff5117L36),
but wasn't backfilled with stencil's `@utils` package version in
`generate-esm.ts`. without this change, the destination computed for the
polyfills is not normalized for users of Windows OS's.

when the destination path is not normalized here (but is normalized in
other parts of the code), it creates a situation where stencil's in
memory-fs both:
1. marks the polyfills to be copied
2. marks the _previous_ polyfills to be removed

normally, if we're performing a copy operation, we don't bother with the
deletion (as the copy overwrites the existing polyfills). this is
important, as stencil performs its copy operations before it performs
its deletions. to ensure that a recently copied file is not subsequently
deleted, stencil performs a [check on the files it will delete and
removes them from the 'to delete' list](https://github.com/ionic-team/stencil/blob/15a7f89f677bad012dd82a088ce64149a7e48a61/src/compiler/sys/in-memory-fs.ts#L1250-L1253)
based on the destination filename.

since the destination filename on windows is not normalized and the
filename for the same file to delete is (normalized), the check fails to
acknowledge we're going to copy this file. this causes the following
behavior on a stencil build:
- if the polyfills directory exists, mark it to be copied, but
  subsequently delete it
- if the polyfills directory does not exist, mark it to be copied. it
  will not be marked to be deleted because it does not exist on disk
  when the list of files to delete is calculated (prior to the copy)

in #4317 (b042d8b), a polyfill for node's `path.join` was [removed](https://github.com/ionic-team/stencil/pull/4317/files#diff-734f69edf83052dfd5ce6df10429550680537c6da66ef9b7cfbda11efdff5117L36),
but wasn't backfilled with stencil's `@utils` package version in
`generate-esm.ts`. without this change, the destination computed for the
polyfills is not normalized for users of Windows OS's.

when the destination path is not normalized here (but is normalized in
other parts of the code), it creates a situation where stencil's in
memory-fs both:
1. marks the polyfills to be copied
2. marks the _previous_ polyfills to be removed

normally, if we're performing a copy operation, we don't bother with the
deletion (as the copy overwrites the existing polyfills). this is
important, as stencil performs its copy operations before it performs
its deletions. to ensure that a recently copied file is not subsequently
deleted, stencil performs a [check on the files it will delete and
removes them from the 'to delete' list](https://github.com/ionic-team/stencil/blob/15a7f89f677bad012dd82a088ce64149a7e48a61/src/compiler/sys/in-memory-fs.ts#L1250-L1253)
based on the destination filename.

since the destination filename on windows is not normalized and the
filename for the same file to delete is (normalized), the check fails to
acknowledge we're going to copy this file. this causes the following
behavior on a stencil build:
- if the polyfills directory exists, mark it to be copied, but
  subsequently delete it
- if the polyfills directory does not exist, mark it to be copied. it
  will not be marked to be deleted because it does not exist on disk
  when the list of files to delete is calculated (prior to the copy)

Fixes: #4661

STENCIL-918

in #4317 (b042d8b), a polyfill for node's `path.join` was [removed](https://github.com/ionic-team/stencil/pull/4317/files#diff-734f69edf83052dfd5ce6df10429550680537c6da66ef9b7cfbda11efdff5117L36),
but wasn't backfilled with stencil's `@utils` package version in
`generate-esm.ts`. without this change, the destination computed for the
polyfills is not normalized for users of Windows OS's.

when the destination path is not normalized here (but is normalized in
other parts of the code), it creates a situation where stencil's in
memory-fs both:
1. marks the polyfills to be copied
2. marks the _previous_ polyfills to be removed

normally, if we're performing a copy operation, we don't bother with the
deletion (as the copy overwrites the existing polyfills). this is
important, as stencil performs its copy operations before it performs
its deletions. to ensure that a recently copied file is not subsequently
deleted, stencil performs a [check on the files it will delete and
removes them from the 'to delete' list](https://github.com/ionic-team/stencil/blob/15a7f89f677bad012dd82a088ce64149a7e48a61/src/compiler/sys/in-memory-fs.ts#L1250-L1253)
based on the destination filename.

since the destination filename on windows is not normalized and the
filename for the same file to delete is (normalized), the check fails to
acknowledge we're going to copy this file. this causes the following
behavior on a stencil build:
- if the polyfills directory exists, mark it to be copied, but
  subsequently delete it
- if the polyfills directory does not exist, mark it to be copied. it
  will not be marked to be deleted because it does not exist on disk
  when the list of files to delete is calculated (prior to the copy)

Fixes: #4661

STENCIL-918

this patch ensures that paths are properly normalized by the compiler.
this ensures that regardless of the platform (operating system) that a
project is compiled on, paths are uniformly treated internally by
stencil. this has system-wide reaching effects - from the in-memory
filesystem, to configuration/output target validation, and file
generation.

previously, stencil's in-browser compilation support included a polyfill
for the following NodeJS `path` module functions: `join`, `normalize`,
`relative` & `resolve`. this polyfill did the following:
- it wrapped each of the aforementioned functions in a `normalizePath`
  function to convert Windows-style path separators (`\\`) to
  Unix/POSIX-style path separators (`/`)
- it overwrote the standard NodeJS `path` implementations for each of
  these functions.
as a result, calling `join` or any of the other three methods, even when
importing the method from `path` like below would result in the polyfill
being called:
```ts
import { join } from 'path'; // this imports the polyfilled `join`

// runs the native `path.join`, then normalizes the returned path
const filePath = join(part1, part2);
```

while this was 'nice' in that stencil engineers didn't need to think
about which implementation of `path` functions they were using, this
polyfill made some behavior of the compiler hard to understand.

the polyfills were removed in #4317 (b042d8b). this led to calls to the
aforementioned functions to call their original implementations, rather
than the wrapped implementations:
```ts
import { join } from 'path'; // imports Node's `join`

// run the native `path.join`, without any normalization
const filePath = join(part1, part2);
```

discrepencies arose where parts of the code would explicitly wrap a
call to `join()` (or one of its ilk) around a path normalization
function. this caused paths to not be uniformly normalized throughout
the codebase, leading to errors.

since the removal of in-browser compilation, additional pull requests
to fix path-related issues on windows have landed in the codebase:
- #4545 (cd58d9c)
- #4932 (b97dadc)

this commit builds on the previous commits by attempting to move
stencil's compiler completely over to polyfilled versions of the
mentioned `path` functions that are explicitly imported/called.

Some of the changes found herein were created/validated using Alice's
codemod branch, #4996
Co-authored-by: alicewriteswrongs <alicewriteswrongs@users.noreply.github.com>

STENCIL-975 Determine Scope of Path Polyfill Bug, Fix

Fixes: #4980
Fixes: #4961

Spun Off: #5036, #5032, #5029

* fix(compiler): normalize paths on windows

this patch ensures that paths are properly normalized by the compiler.
this ensures that regardless of the platform (operating system) that a
project is compiled on, paths are uniformly treated internally by
stencil. this has system-wide reaching effects - from the in-memory
filesystem, to configuration/output target validation, and file
generation.

previously, stencil's in-browser compilation support included a polyfill
for the following NodeJS `path` module functions: `join`, `normalize`,
`relative` & `resolve`. this polyfill did the following:
- it wrapped each of the aforementioned functions in a `normalizePath`
  function to convert Windows-style path separators (`\\`) to
  Unix/POSIX-style path separators (`/`)
- it overwrote the standard NodeJS `path` implementations for each of
  these functions.
as a result, calling `join` or any of the other three methods, even when
importing the method from `path` like below would result in the polyfill
being called:
```ts
import { join } from 'path'; // this imports the polyfilled `join`

// runs the native `path.join`, then normalizes the returned path
const filePath = join(part1, part2);
```

while this was 'nice' in that stencil engineers didn't need to think
about which implementation of `path` functions they were using, this
polyfill made some behavior of the compiler hard to understand.

the polyfills were removed in #4317 (b042d8b). this led to calls to the
aforementioned functions to call their original implementations, rather
than the wrapped implementations:
```ts
import { join } from 'path'; // imports Node's `join`

// run the native `path.join`, without any normalization
const filePath = join(part1, part2);
```

discrepencies arose where parts of the code would explicitly wrap a
call to `join()` (or one of its ilk) around a path normalization
function. this caused paths to not be uniformly normalized throughout
the codebase, leading to errors.

since the removal of in-browser compilation, additional pull requests
to fix path-related issues on windows have landed in the codebase:
- #4545 (cd58d9c)
- #4932 (b97dadc)

this commit builds on the previous commits by attempting to move
stencil's compiler completely over to polyfilled versions of the
mentioned `path` functions that are explicitly imported/called.

Some of the changes found herein were created/validated using Alice's
codemod branch, #4996
Co-authored-by: alicewriteswrongs <alicewriteswrongs@users.noreply.github.com>

STENCIL-975 Determine Scope of Path Polyfill Bug, Fix

Fixes: #4980
Fixes: #4961

Spun Off: #5036, #5032, #5029

* fix validate-dist-collection tests

* fix prerendered-write-path test

* fix stencil-types tests

this commit removes a spy on `join.resolve` and updates the mocks to
properly spy on the wrapped `@utils`' `resolve` fn

* fix validate-paths tests

this commit updates the tests for `validate-paths`. it replaces
instances of `path.join` in assertions with stencil's own `join`
function. existing instances of `path.join` have been left as-is if they
pertain to user input. this allows us to exercise a user using either
path separator in CI (which runs in windows and linux).

the cache directory is now normalized if it is absolute. otherwise,
provided cache directories in `stencil.config.ts` would never get
normalized

* fix validate-output-www tests

this commit updates the tests for `validate-paths`. it replaces
instances of `path.join` in assertions with stencil's own `join`
function. existing instances of `path.join` have been left as-is if they
pertain to user input. this allows us to exercise a user using either
path separator in CI (which runs in windows and linux).

* fix validate-output-dist tests

this commit updates the tests for `validate-output`. it replaces
instances of `path.join` in assertions with stencil's own `join`
function. existing instances of `path.join` have been left as-is if they
pertain to user input. this allows us to exercise a user using either
path separator in CI (which runs in windows and linux).

this commit also switches `output-target.ts#getcomponentsDtsSrcFilePath`
over to use Stencil's join function to fix the tests

* fix validate-output-dist-custom-element tests

this commit updates the tests for `validate-output-dist-custom-element`.
it replaces instances of `path.join` in assertions with stencil's own `join
function. existing instances of `path.join` have been left as-is if they
pertain to user input. this allows us to exercise a user using either
path separator in CI (which runs in windows and linux).

* fix validate-testing tests

this commit updates the tests for `validate-testing`. it replaces
instances of `path.join` in assertions with stencil's own `join`
function. existing instances of `path.join` have been left as-is if they
pertain to user input. this allows us to exercise a user using either
path separator in CI (which runs in windows and linux).

the screenshot connector is now normalized if it is absolute. otherwise,
provided connector file path in `stencil.config.ts` would never get
normalized

This JSDoc comment is currently outdated because it makes reference to a
browser-specific `Logger` impl which we no longer have (it was deleted
in #4317).