[Snyk] Upgrade: , lit-element, , , , , , , , , , , , , , , , chai, dom5, dot-prop-immutable, escodegen, espree, eslint, eslint-config-google, eslint-plugin-html, karma, karma-chrome-launcher, karma-coverage, karma-mocha, karma-sourcemap-loader, karma-webpack, mocha, puppeteer, redux, sinon, webpack, webpack-command #12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Snyk has created this PR to upgrade multiple dependencies.
👯♂ The following dependencies are linked and will therefore be updated together.ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.
@chopsui/batch-iterator
⚠️ This is a major version upgrade, and may be a breaking change | a month ago
⚠️ This is a major version upgrade, and may be a breaking change | 5 years ago
⚠️ This is a major version upgrade, and may be a breaking change | 4 months ago
⚠️ This is a major version upgrade, and may be a breaking change | 6 years ago
⚠️ This is a major version upgrade, and may be a breaking change | 3 years ago
⚠️ This is a major version upgrade, and may be a breaking change | a year ago
⚠️ This is a major version upgrade, and may be a breaking change | 3 months ago
⚠️ This is a major version upgrade, and may be a breaking change | a month ago
⚠️ This is a major version upgrade, and may be a breaking change | 5 months ago
⚠️ This is a major version upgrade, and may be a breaking change | 2 months ago
⚠️ This is a major version upgrade, and may be a breaking change | a year ago
⚠️ This is a major version upgrade, and may be a breaking change | a year ago
⚠️ This is a major version upgrade, and may be a breaking change | 4 years ago
⚠️ This is a major version upgrade, and may be a breaking change | 8 months ago
⚠️ This is a major version upgrade, and may be a breaking change | a month ago
⚠️ This is a major version upgrade, and may be a breaking change | 21 days ago
⚠️ This is a major version upgrade, and may be a breaking change | 9 months ago
⚠️ This is a major version upgrade, and may be a breaking change | 4 months ago
⚠️ This is a major version upgrade, and may be a breaking change | a month ago
from 0.1.0 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
lit-element
from 2.1.0 to 4.1.0 | 44 versions ahead of your current version
on 2024-08-05
@chopsui/chops-button
from 0.1.11 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-checkbox
from 0.1.11 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-header
from 0.1.5 to 0.3.6 | 10 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-input
from 0.1.11 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-loading
from 0.1.11 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-radio
from 0.1.11 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-radio-group
from 0.1.11 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-signin
from 0.1.5 to 0.3.6 | 10 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-switch
from 0.1.11 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-tab
from 0.1.11 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-tab-bar
from 0.1.11 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/chops-textarea
from 0.1.11 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/result-channel
from 0.1.0 to 0.3.6 | 9 versions ahead of your current version | a year ago
on 2023-06-27
@chopsui/tsmon-client
from 0.0.1 to 1.0.1 | 2 versions ahead of your current version
on 2019-06-04
@polymer/polymer
from 3.2.0 to 3.5.1 | 6 versions ahead of your current version | 2 years ago
on 2022-06-03
chai
from 4.2.0 to 5.1.1 | 23 versions ahead of your current version
on 2024-05-09
dom5
from 1.3.6 to 3.0.1 | 7 versions ahead of your current version
on 2018-06-28
dot-prop-immutable
from 1.5.0 to 2.1.1 | 4 versions ahead of your current version
on 2021-07-17
escodegen
from 1.11.0 to 2.1.0 | 10 versions ahead of your current version
on 2023-06-29
espree
from 3.5.4 to 10.1.0 | 39 versions ahead of your current version
on 2024-06-17
eslint
from 4.19.1 to 9.9.1 | 176 versions ahead of your current version
on 2024-08-23
eslint-config-google
from 0.6.0 to 0.14.0 | 11 versions ahead of your current version | 5 years ago
on 2019-09-02
eslint-plugin-html
from 4.0.5 to 8.1.1 | 21 versions ahead of your current version
on 2024-04-22
karma
from 4.1.0 to 6.4.4 | 55 versions ahead of your current version
on 2024-07-29
karma-chrome-launcher
from 2.2.0 to 3.2.0 | 4 versions ahead of your current version
on 2023-04-20
karma-coverage
from 1.1.2 to 2.2.1 | 8 versions ahead of your current version
on 2023-06-23
karma-mocha
from 1.3.0 to 2.0.1 | 2 versions ahead of your current version
on 2020-04-29
karma-sourcemap-loader
from 0.3.7 to 0.4.0 | 2 versions ahead of your current version | 2 years ago
on 2023-02-05
karma-webpack
from 4.0.0-rc.6 to 5.0.1 | 12 versions ahead of your current version
on 2024-02-01
mocha
from 5.2.0 to 10.7.3 | 58 versions ahead of your current version
on 2024-08-09
puppeteer
from 1.15.0 to 23.2.1 | 264 versions ahead of your current version
on 2024-08-29
redux
from 4.0.1 to 5.0.1 | 23 versions ahead of your current version
on 2023-12-23
sinon
from 7.3.2 to 18.0.0 | 52 versions ahead of your current version
on 2024-05-15
webpack
from 4.23.1 to 5.94.0 | 299 versions ahead of your current version
on 2024-08-22
webpack-command
from 0.4.1 to 0.5.1 | 3 versions ahead of your current version | 3 years ago
on 2021-04-01
Issues fixed by the recommended upgrade:
SNYK-JS-ELLIPTIC-571484
SNYK-JS-ENGINEIO-1056749
SNYK-JS-ACORN-559469
SNYK-JS-BROWSERIFYSIGN-6037026
SNYK-JS-DECODEURICOMPONENT-3149970
SNYK-JS-INI-1048974
SNYK-JS-UNSETVALUE-2400660
SNYK-JS-USERAGENT-174737
SNYK-JS-SOCKETIOPARSER-1056752
SNYK-JS-TAR-1536528
SNYK-JS-TAR-1579147
SNYK-JS-DOTPROP-543489
SNYK-JS-ELLIPTIC-1064899
SNYK-JS-ELLIPTIC-511941
SNYK-JS-ELLIPTIC-7577916
SNYK-JS-ELLIPTIC-7577917
SNYK-JS-ELLIPTIC-7577918
SNYK-JS-LODASH-450202
SNYK-JS-HANDLEBARS-469063
SNYK-JS-HANDLEBARS-480388
SNYK-JS-HANDLEBARS-534478
SNYK-JS-ASYNC-2441827
SNYK-JS-BRACES-6838727
SNYK-JS-ENGINEIO-3136336
SNYK-JS-FOLLOWREDIRECTS-6141137
SNYK-JS-GETFUNCNAME-5923417
SNYK-JS-HANDLEBARS-1056767
SNYK-JS-MIXINDEEP-450212
SNYK-JS-MOCHA-2863123
SNYK-JS-MOCHA-561476
SNYK-JS-TAR-6476909
SNYK-JS-HANDLEBARS-1279029
SNYK-JS-WS-1296835
SNYK-JS-MINIMIST-559764
SNYK-JS-MINIMIST-559764
SNYK-JS-HANDLEBARS-567742
SNYK-JS-HTTPPROXY-569139
SNYK-JS-HTTPSPROXYAGENT-469131
SNYK-JS-FOLLOWREDIRECTS-2332181
SNYK-JS-FOLLOWREDIRECTS-6444610
SNYK-JS-GLOBPARENT-1016905
SNYK-JS-PATHVAL-596926
SNYK-JS-UGLIFYJS-1727251
SNYK-JS-MINIMIST-2429795
SNYK-JS-HANDLEBARS-534988
SNYK-JS-BABELTRAVERSE-5962462
SNYK-JS-PATHTOREGEXP-7925106
SNYK-JS-SOCKETIO-1024859
SNYK-JS-SOCKETIOPARSER-3091012
SNYK-JS-SSRI-1246392
SNYK-JS-TAR-1536531
SNYK-JS-TAR-1579152
SNYK-JS-TAR-1579155
SNYK-JS-WEBPACKDEVMIDDLEWARE-6476555
SNYK-JS-WS-7266574
SNYK-JS-SERIALIZEJAVASCRIPT-536840
SNYK-JS-SERIALIZEJAVASCRIPT-570062
SNYK-JS-SERIALIZEJAVASCRIPT-6056521
SNYK-JS-SETVALUE-1540541
SNYK-JS-SETVALUE-450213
SNYK-JS-SETVALUE-1540541
SNYK-JS-SETVALUE-450213
SNYK-JS-LODASH-1040724
SNYK-JS-LODASH-567746
SNYK-JS-LODASH-608086
SNYK-JS-LODASH-6139239
SNYK-JS-LODASH-1040724
SNYK-JS-MICROMATCH-6838728
SNYK-JS-WS-7266574
SNYK-JS-XMLHTTPREQUESTSSL-1082936
SNYK-JS-XMLHTTPREQUESTSSL-1255647
SNYK-JS-Y18N-1021887
SNYK-JS-KARMA-2395349
SNYK-JS-KARMA-2396325
SNYK-JS-WEBPACK-7840298
SNYK-JS-WS-1296835
SNYK-JS-SERIALIZEJAVASCRIPT-6147607
SNYK-JS-LODASH-1018905
SNYK-JS-LODASH-1018905
SNYK-JS-LOG4JS-2348757
SNYK-JS-FOLLOWREDIRECTS-2396346
SNYK-JS-TAR-1536758
SNYK-JS-KINDOF-537849
SNYK-JS-MINIMIST-2429795
npm:debug:20170905
npm:debug:20170905
Release notes
Package name: lit-element
Package name: @polymer/polymer
3.5.1
3.5.0
[ci skip] bump to 3.4.1 (commit)
Add type for DomApiNative's setAttribute method. (commit)
Remove gen-typescript-declarations; manually add LegacyElementMixin's setAttribute type. (commit)
Remove "DO NOT EDIT" warning comments. (commit)
Track TypeScript declarations. (commit)
Update Closure types for overridden setAttribute in LegacyElementMixin. (commit)
Add method / parameter descriptions. (commit)
Fix TypeScript breakages by specifying types for overridden
setAttribute
andgetAttribute
. (commit)Add complete commit list for v3.4.0 (commit)
Fix a couple more compiler warnings (commit)
Typos and other minor changes. (commit)
Add a note about a bug fix for chunking. (commit)
Add
useAdoptedStyleSheetsWithBuiltCSS
section. (commit)Add setters to settings titles. (commit)
Add a note about
orderedComputed
and cycles. (commit)Add example of overriding
suppressTemplateNotifications
vianotify-dom-change
. (commit)Add a section about automatic use of constructable stylesheets. (commit)
Add "Other new features" section for
reuseChunkedInstances
andLegacyElementMixin
's built-indisable-upgrade
support. (commit)Added notes for
fastDomIf
,removeNestedTemplates
,suppressNestedTemplates
, andsuppressTemplateNotifications
. (commit)Started on release notes for
legacyUndefined
,legacyWarnings
,orderedComputed
. (...) (commit)Remove unused externs. (commit)
v3.4.0...v3.4.1
New global settings
This update to Polymer includes some new global settings:
legacyUndefined
/setLegacyUndefined
What does it do? This setting reverts how computed properties handle
undefined
values to the Polymer 1 behavior: when enabled, computed properties will only be recomputed if none of their dependencies areundefined
.Components can override the global setting by setting their
_overrideLegacyUndefined
property totrue
. This is useful for reenabling the default behavior as you migrate individual components:Should I use it? This setting should only be used for migrating legacy codebases that depend on this behavior and is otherwise not recommended.
legacyWarnings
/setLegacyWarnings
What does it do? This setting causes Polymer to warn if a component's template contains bindings to properties that are not listed in that element's
properties
block. For example:Only properties explicitly declared in the
properties
block are associated with an attribute and update when that attribute changes. Enabling this setting will show you where you might have forgotten to declare properties.Should I use it? Consider using this feature during development but don't enable it in production.
orderedComputed
/setOrderedComputed
What does it do? This setting causes Polymer to topologically sort each component's computed properties graph when the class is initialized and uses that order whenever computed properties are run.
For example:
When
a
changes, Polymer's default behavior does not specify the order in which its dependents will run. Given that bothb
andc
depend directly ona
, one of two possible orders could occur: [computeB
,computeC
] or [computeC
,computeB
].In the first case - [
computeB
,computeC
] -computeB
is run with the new value ofa
and produces a new value forb
. Then,computeC
is run with both the new values ofa
andb
to producec
.In the second case - [
computeC
,computeB
] -computeC
is run first with the new value ofa
and the current value ofb
to producec
. Then,computeB
is run with the new value ofa
to produceb
. IfcomputeB
changed the value ofb
thencomputeC
will be run again, with the new values of botha
andb
to produce the final value ofc
.However, with
orderedComputed
enabled, the computed properties would have been previously sorted into [computeB
,computeC
], so updatinga
would cause them to run specifically in that order.If your component's computed property graph contains cycles, the order in which they are run when using
orderedComputed
is still undefined.Should I use it? The value of this setting depends on how your computed property functions are implemented. If they are pure and relatively inexpensive, you shouldn't need to enable this feature. If they have side effects that would make the order in which they are run important or are expensive enough that it would be a problem to run them multiple times for a property update, consider enabling it.
fastDomIf
/setFastDomIf
What does it do? This setting enables a different implementation of
<dom-if>
that uses its host element's template stamping facilities (provided as part ofPolymerElement
) rather than including its own. This setting can help with performance but comes with a few caveats:First,
fastDomIf
requires that every<dom-if>
is in the shadow root of a Polymer element: you can't use a<dom-if>
directly in the main document or inside a shadow root of an element that doesn't extendPolymerElement
.Second, because the
fastDomIf
implementation of<dom-if>
doesn't include its own template stamping features, it doesn't create its own scope for property effects. This means that any properties you were previously setting on the<dom-if>
will no longer be applied within its template, only properties of the host element are available.Should I use it? This setting is recommended as long as your app doesn't use
<dom-if>
as described in the section above.removeNestedTemplates
/setRemoveNestedTemplates
What does it do? This setting causes Polymer to remove the child
<template>
elements used by<dom-if>
and<dom-repeat>
from the their containing templates. This can improve the performance of cloning your component's template when new instances are created.Should I use it? This setting is generally recommended.
suppressTemplateNotifications
/setSuppressTemplateNotifications
What does it do? This setting causes
<dom-if>
and<dom-repeat>
not to dispatchdom-change
events when their rendered content is updated. If you're using lots of<dom-if>
and<dom-repeat>
but not listening for these events, this setting lets you disable them and their associated dispatch work.You can override the global setting for an individual
<dom-if>
or<dom-repeat>
by setting itsnotify-dom-change
boolean attribute:Should I use it? This setting is generally recommended.
legacyNoObservedAttributes
/setLegacyNoObservedAttributes
What does it do? This setting causes
LegacyElementMixin
not to use the browser's built-in mechanism for informing elements of attribute changes (i.e.observedAttributes
andattributeChangedCallback
), which lets Polymer skip computing the list of attributes it tells the browser to observe. Instead,LegacyElementMixin
simulates this behavior by overriding attribute APIs on the element and callingattributeChangedCallback
itself.This setting has similar API restrictions to those of the custom elements polyfill. You should only use the element's
setAttribute
andremoveAttribute
methods to modify attributes: using (e.g.) the element'sattributes
property to modify its attributes is not supported withlegacyNoObservedAttributes
and won't properly triggerattributeChangedCallback
or any property effects.Components can override the global setting by setting their
_legacyForceObservedAttributes
property totrue
. This property's effects occur at startup; it won't have any effect if modified at runtime and should be set in the class definition.Should I use it? This setting should only be used if startup time is significantly affected by Polymer's class initialization work - for example, if you have a large number of components being loaded but are only instantiating a small subset of them. Otherwise, this setting is not recommended.
useAdoptedStyleSheetsWithBuiltCSS
/setUseAdoptedStyleSheetsWithBuiltCSS
What does it do? If your application is uses pre-built Shady CSS styles and your browser supports constructable stylesheet objects, this setting will cause Polymer to extract all
<style>
elements from your components' templates, join them into a single stylesheet, and share this stylesheet with all instances of the component using their shadow roots'adoptedStyleSheets
array. This setting may improve your components' memory usage and performance depending on how many instances you create and how large their style sheets are.Should I use it? Consider using this setting if your app already uses pre-built Shady CSS styles. Note that position-dependent CSS selectors (e.g. containing
:nth-child()
) may become unreliable for siblings of your components' styles as a result of runtime-detected browser support determining if styles are removed from your components' shadow roots.Other new features
<dom-repeat>
reuseChunkedInstances
What does it do? This boolean property causes
<dom-repeat>
to reuse template instances even whenitems
is replaced with a new array, matching the Polymer 1 behavior.By default, a
<dom-repeat>
with chunking enabled (i.e.initialCount
>= 0) will drop all previously rendered template instances and create new ones whenever theitems
array is replaced. WithreuseChunkedInstances
set, any previously rendered template instances will instead be repopulated with data from the new array before new instances are created.Should I use it? This flag is generally recommended and can improve rendering performance of chunked
<dom-repeat>
instances with live data.LegacyElementMixin
disable-upgrade
What does it do?
LegacyElementMixin
now has built-in support for thedisable-upgrade
attribute (usually provided byDisableUpgradeMixin
) that becomes active when the globallegacyOptimizations
setting is enabled, matching the Polymer 1 behavior.Should I use it? Consider using this setting if you are already using the
legacyOptimizations
setting and migrating older components that depend ondisable-upgrade
without explicit application ofDisableUpgradeMixin
.Bug fixes
<dom-repeat>
Chunking behavior
<dom-repeat>
no longer resets the number of rendered instances toinitialCount
when modifyingitems
withPolymerElement
's array modification methods (splice
,push
, etc.). The number of rendered instances will only be reset toinitialCount
if theitems
array itself is replaced with a new array object.See #5631 for more information.
All commits
[ci skip] bump to 3.4.0 (commit)
shareBuiltCSSWithAdoptedStyleSheets
->useAdoptedStyleSheetsWithBuiltCSS
(commit)formatting (commit)
Fix incorrect JSDoc param name. (commit)
Gate feature behind
shareBuiltCSSWithAdoptedStyleSheets
; update tests. (commit)Add
shareBuiltCSSWithAdoptedStyleSheets
global setting (commit)Add stalebot config (commit)
Annotate more return types as !defined (#5642) (commit)
Ensure any previously enqueued rAF is canceled when re-rendering. Also, use instances length instead of renderedItemCount since it will be undefined on first render. (commit)
Improve comment. (commit)
Remove obsolete tests. (commit)
Simplify by making limit a derived value from existing state. This centralizes the calculation of limit based on changes to other state variables. (commit)
Update Sauce config to drop Safari 9, add 12 & 13. Safari 9 is now very old, and has micro task ordering bugs issues that make testing flaky. (commit)
Remove accidental commit of test.only (commit)
When re-enabling, ensure __limit is at a good starting point and add a test for that. Also: * Ensure
__itemsArrayChanged
is cleared after every render. * Enqueue__continueChunkingAfterRaf
before notifying renderedItemCount for safety (commit)Remove accidental commit of suite.only (commit)
Ensure limit is reset when initialCount is disabled. Note that any falsey value for initialCount (including
0
) is interpreted as "chunking disabled". This is consistent with 1.x logic, and follows from the logic of "starting chunking by rendering zero items" doesn't really make sense. (commit)Updates from review. * Refactoring
__render
for readability * Removing__pool
; this was never used in v2: since we reset the pool every update and items are only ever pushed at detach time and we only detach at the end of updates (as opposed to v1 which had more sophisticated splicing) (commit)Store syncInfo on the dom-if, but null it in teardown. (same as invalidProps ...