Instead, we can dynamically require "stream" with an expression
that prevents it from being bundled in client-side bundling
processes. This may still fail in some folding scenarios, but
I've personally successfully applied it here before:
3455401e6f/exchanges/persisted-fetch/src/sha256.ts (L33-L40)
This is guaranteed to at least work against Webpack, Rollup, and
other 'primitive' bundlers.
The internal decision whether to forward a prop is based on the
combination of the key and elementToBeCreated, but only the former was
passed to shouldForwardProp.
This is a port of #3436 to legacy-v5
If `styled` should come from a wrapper instead of directly from
styled-components, this enables users of the macro to customize the
import by configuring in `packages.json`:
"babelMacros": {
"styledComponents": {
"importModuleName": "my-styled-components"
}
}
Previously similar functionality landed in
babel-plugin-styled-components so users of the plugin could use
a wrapper at that level, but it wasn't available to users of the macro.
This builds on that work by passing the customized module name through
to the plugin. Consequently we also update the dependency to ensure the
plugin supports `topLevelImportPaths`
See 325167bb57
Fixes https://github.com/gregberge/xstyled/issues/44
Cherry picked from 83c8b0ccd0
When developing for react native, components are sometimes marked with
the `testID` prop. This prop is functionally similar to the
`data-testid` attached for react web components.
Unfortunately, styled components for react native didn't pass this prop
down, making it difficult for react native test frameworks like Detox to
test.
This change fixes that so when a `testID` prop is specified for a styled
component for react-native, it is passed down to the corresponding
native component it represents
* fix: Allow `DISABLE_SPEEDY` to be set to `false`
The old initialization of `DISABLE_SPEEDY` meant that the only way it could be set to a falsey value was if `NODE_ENV` was set to `production` and no other setting was set. Setting `SC_DISABLE_SPEEDY` or the environment variables to false would be overridden by `NODE_ENV`.
The new initialization ensures that if one of these options is set, it’s value is respected.
This change should only affect the computed value of `DISABLE_SPEEDY` if one of the settings has the value `false` or `’false’`. Otherwise it should have the same truthy or falsey value.
Since the expected behavior of setting one of the configuration variables to `false` is to have `DISABLE_SPEEDY` set to false, this should be a fix and not a breaking change.
* test: Add tests for setting `DISABLE_SPEEDY` to `false`
* fix: Ensure `DISABLE_SPEEDY` boolean type
Technically not needed, but makes the tests pass when passing in the string values of `’false’` without needing to modify the compare values. And is a bit cleaner to have it as a boolean type.
* fix: Inline `process.env` references
Per [this comment](https://github.com/styled-components/styled-components/pull/3289#issuecomment-699171576)
* docs: Add changelog entry
* use github actions
* remove travis
* fix step name
* do less work
* switch to bundlewatch
* set proper branch
* fix repo name env variable
* try running on branch instead