![Create React App Officially Deprecated Amid React 19 Compatibility Issues](https://cdn.sanity.io/images/cgdhsj6q/production/04fa08cf844d798abc0e1a6391c129363cc7e2ab-1024x1024.webp?w=400&fit=max&auto=format)
Security News
Create React App Officially Deprecated Amid React 19 Compatibility Issues
Create React App is officially deprecated due to React 19 issues and lack of maintenance—developers should switch to Vite or other modern alternatives.
flake8-logging-format
Advanced tools
Flake8 extension to validate (lack of) logging format strings
Python logging supports a special extra
keyword
for passing a dictionary of user-defined attributes to include in a logging event. One way to ensure consistency and
rigor in logging is to always use extra
to pass non-constant data and, therefore, to never use format strings,
concatenation, or other similar techniques to construct a log string.
In other words, do this:
logger.info(
"Hello {world}",
extra=dict(
world="Earth"
)
)
Instead of:
logger.info(
"Hello {world}".format(world=Earth)
)
As a further level of rigor, we can enforce that extra
dictionaries only use keys from a well-known whitelist.
Usage:
flake8 --enable-extra-whitelist
The built-in Whitelist
supports plugins using entry_points
with a key of "logging.extra.whitelist"
. Each
registered entry point must be a callable that returns an iterable of string.
In some cases you may want to log sensitive data only in debugging scenarios. This is supported in 2 ways:
debug
levelG001
Logging statements should not use string.format()
for their first argumentG002
Logging statements should not use %
formatting for their first argumentG003
Logging statements should not use +
concatenation for their first argumentG004
Logging statements should not use f"..."
for their first argument (only in Python 3.6+)G010
Logging statements should not use warn
(use warning
instead)G100
Logging statements should not use extra
arguments unless whitelistedG101
Logging statement should not use extra
arguments that clash with LogRecord fieldsG200
Logging statements should not include the exception in logged string (use exception
or exc_info=True
)G201
Logging statements should not use error(..., exc_info=True)
(use exception(...)
instead)G202
Logging statements should not use redundant exc_info=True
in exception
These violations are disabled by default. To enable them for your project, specify the code(s) in your setup.cfg
:
[flake8]
enable-extensions=G
Our motivation has to do with balancing the needs of our team and those of our customers. On the one hand, developers and front-line support should be able to look at application logs. On the other hand, our customers don't want their data shared with anyone, including internal employees.
The implementation approaches this in two ways:
By trying to prevent the use of string concatenation in logs (vs explicit variable passing in the standard logging extra
dictionary)
By providing an (optional) mechanism for whitelisting which field names may appear in the extra
dictionary
Naturally, this does not prevent developers from doing something like:
extra=dict(
user_id=user.name,
)
but then avoiding a case like this falls back to other processes around pull-requests, code review and internal policy.
FAQs
Unknown package
We found that flake8-logging-format demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Create React App is officially deprecated due to React 19 issues and lack of maintenance—developers should switch to Vite or other modern alternatives.
Security News
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.
Security News
The Linux Foundation is warning open source developers that compliance with global sanctions is mandatory, highlighting legal risks and restrictions on contributions.