eUgEntOptIc44/uBlock
1
1
Fork 0
mirror of https://github.com/gorhill/uBlock.git synced 2025-10-05 21:32:39 +02:00
Code Issues Releases Wiki Activity
Files
master
uBlock/Makefile

188 lines
4.9 KiB
Makefile
Raw Permalink Normal View History

Add platform "dig", to experiment/validate code changes This is a replacement for the dubious approach when the extension itself was used to run benchmarks to detect performance and filtering behavior regressions.
2021-08-15 15:47:40 -04:00
# https://stackoverflow.com/a/6273809
run_options := $(filter-out $@,$(MAKECMDGOALS))
[mv3] Add support to add/remove rulesets through policies Related discussion: https://github.com/uBlockOrigin/uBOL-home/discussions/35#discussioncomment-11157444 New policy setting: `rulesets` Type: array Type of array items: string Each item in the list is a list id (as seen in `rulesets/ruleset-details.json`), prefixed with either `+` to enable the ruleset, or `-` to disable the ruleset. Users will not be able to enable or disable rulesets present in the `rulesets` policy. Disabled rulesets will not appear in the dashboard. Use `-*` to remove all non-default rulesets, except for those added using `+[ruleset_id]`. Additionally, some work has been done to properly handle policy changes in a non-blocking and deferred manner, as I observed that it often takes long for calls to `storage.manage.get` to resolve. This potentailly takes care of the following issue: https://github.com/uBlockOrigin/uBOL-home/issues/174
2024-11-11 13:20:54 -05:00
.PHONY: all clean cleanassets test lint chromium opera firefox npm dig \
[mv3] Add support for custom DNR rules This feature is hidden behind the "Developer mode" setting in the dashboard. When "Developer mode" is enabled, a tab named "Develop" will become available in the dashboard. This tab is meant to contain tools for technical users. At the moment, the "Develop" pane allows to create custom DNR rules through a (CodeMirror-based) editor. For the sake of convenience, the DNR rule must be entered in YAML-like format. The format is not really full compliant YAML, just YAML-like, and very strict in order to ensure the parser stays simple enough. Lines starting with `#` are comments and will be ignored by the parser. Any line which do not match the parser's expectation will be marked as invalid, and the whole DNR rule containing such invalid lines will be discarded. There must not be empty lines inside a rule definition. Each DNR rule must be separated with a `---` line, which is known as a YAML document separator. String values must not be quoted, otherwise the quotes will be considered part of the value. There is one exception: `''` will be parsed as "an empty string". The editor will attempt to auto-complete known DNR keywords. That feature will improve over time. Though the parser will identify some errors, not all invalid DNR rules are currently identified by the parser, and these will be reported when the rules are registered through the DNR API. Better identifying invalid DNR rules at edit time will improve over time. The editor will report `regexFilter` values which are not supported by the DNR engine on the current platform. The editor reacts to instances of `regexFilter: ...` to report whether a regex value is supported. This means you can test for a regex value by using `# regexFilter: ...` so that you do not have to create an actual DNR rules just for the sake of testing. Custom DNR rules can be exported into a JSON file (a format known by the DNR API as a "static ruleset"). JSON-based ruleset can be imported, the content will be converted to YAML-like syntax. The editor will attempt to convert to YAML pasted content which can be JSON-parsed. It's possible to paste partially or wholly JSON-based rulesets. When disabling "Developer mode", all custom DNR rules will be unregistered from the DNR API. The DNR rules content will be left intact in such case. Existing DNR rules will be registered into the DNR API when re-enabling "Developer mode". Administrators can prevent "Developer mode" from being enabled by adding `develop` token to `disabledFeatures` setting. Related discussion: https://github.com/uBlockOrigin/uBOL-home/discussions/323 The main motivation is to give list maintainers a tool to assist with resolving filter issues. Custom DNR rules can assist in crafting and validating filters meant to work with uBOL. A secondary motivation is to provide technical users the ability to further customize their content blocker. More conveniences will be added over time, this is a first version.
2025-05-29 09:06:02 -04:00
mv3-chromium mv3-firefox mv3-edge mv3-safari ubol-codemirror \
Improve publish scripts
2025-08-25 15:10:36 -04:00
compare maxcost medcost mincost modifiers record wasm \
Update makefile
2025-09-04 09:51:02 -04:00
publish-chromium publish-edge publish-firefox \
publish-dev-chromium publish-dev-firefox \
upload-firefox upload-dev-firefox
Add Makefile (#3789)
2021-07-31 18:11:28 +05:30
[mv3] Address various issues for Safari build
2025-05-02 14:33:33 -04:00
sources := ./dist/version $(shell find ./assets -type f) $(shell find ./src -type f)
[mv3] Safari works; use 3-component version for uBOL uBOL doesn't pass validation when using 4-component versioning, so falling back to 3-component versioning for all platforms to avoid special case.
2025-05-08 16:53:07 -04:00
platform := $(wildcard platform/*/*)
Use `git clone` instead of submodule to pull uAssets dependencies Related issue: - https://github.com/uBlockOrigin/uBlock-issues/issues/2358 We need two different branches of uAssets to properly add the default filter lists into the packages. I couldn't figure out how to do this with submodules, using simple `git clone` as a dependency just work.
2022-11-14 09:50:53 -05:00
assets := dist/build/uAssets
[mv3] Add support for custom DNR rules This feature is hidden behind the "Developer mode" setting in the dashboard. When "Developer mode" is enabled, a tab named "Develop" will become available in the dashboard. This tab is meant to contain tools for technical users. At the moment, the "Develop" pane allows to create custom DNR rules through a (CodeMirror-based) editor. For the sake of convenience, the DNR rule must be entered in YAML-like format. The format is not really full compliant YAML, just YAML-like, and very strict in order to ensure the parser stays simple enough. Lines starting with `#` are comments and will be ignored by the parser. Any line which do not match the parser's expectation will be marked as invalid, and the whole DNR rule containing such invalid lines will be discarded. There must not be empty lines inside a rule definition. Each DNR rule must be separated with a `---` line, which is known as a YAML document separator. String values must not be quoted, otherwise the quotes will be considered part of the value. There is one exception: `''` will be parsed as "an empty string". The editor will attempt to auto-complete known DNR keywords. That feature will improve over time. Though the parser will identify some errors, not all invalid DNR rules are currently identified by the parser, and these will be reported when the rules are registered through the DNR API. Better identifying invalid DNR rules at edit time will improve over time. The editor will report `regexFilter` values which are not supported by the DNR engine on the current platform. The editor reacts to instances of `regexFilter: ...` to report whether a regex value is supported. This means you can test for a regex value by using `# regexFilter: ...` so that you do not have to create an actual DNR rules just for the sake of testing. Custom DNR rules can be exported into a JSON file (a format known by the DNR API as a "static ruleset"). JSON-based ruleset can be imported, the content will be converted to YAML-like syntax. The editor will attempt to convert to YAML pasted content which can be JSON-parsed. It's possible to paste partially or wholly JSON-based rulesets. When disabling "Developer mode", all custom DNR rules will be unregistered from the DNR API. The DNR rules content will be left intact in such case. Existing DNR rules will be registered into the DNR API when re-enabling "Developer mode". Administrators can prevent "Developer mode" from being enabled by adding `develop` token to `disabledFeatures` setting. Related discussion: https://github.com/uBlockOrigin/uBOL-home/discussions/323 The main motivation is to give list maintainers a tool to assist with resolving filter issues. Custom DNR rules can assist in crafting and validating filters meant to work with uBOL. A secondary motivation is to provide technical users the ability to further customize their content blocker. More conveniences will be added over time, this is a first version.
2025-05-29 09:06:02 -04:00
mv3-sources := \
$(shell find ./src -type f) \
$(wildcard platform/mv3/*) \
$(shell find ./platform/mv3/extension -name codemirror-ubol -prune -o -type f) \
platform/mv3/extension/lib/codemirror/codemirror-ubol/dist/cm6.bundle.ubol.min.js
[mv3] Address various issues for Safari build
2025-05-02 14:33:33 -04:00
mv3-data := $(shell find ./dist/build/mv3-data -type f)
[mv3] Safari works; use 3-component version for uBOL uBOL doesn't pass validation when using 4-component versioning, so falling back to 3-component versioning for all platforms to avoid special case.
2025-05-08 16:53:07 -04:00
mv3-edge-deps := $(wildcard platform/mv3/edge/*)
mv3-safari-deps := $(wildcard platform/mv3/safari/*)
Add Makefile (#3789)
2021-07-31 18:11:28 +05:30
Add support for nodejs flavors The main nodejs flavor is "npm", which is to be used to lint/test and the publication of an official npm package -- and by design it has dependencies on mocha, eslint, etc. A new flavor "dig" has been created with minimal dependencies and which purpose is to easily allow to write specialized code to investigate local code changes in uBO -- and it's not meant for publication. Consequently, "make nodejs" has been replaced with "make npm", and a new "dig" target has been added to the makefile, to be used for instrumenting local code changes for investigation purpose.
2021-08-15 10:43:36 -04:00
all: chromium firefox npm
Add Makefile (#3789)
2021-07-31 18:11:28 +05:30
Add build script as a dependency Related discussion: - https://github.com/gorhill/uBlock/pull/3789#issuecomment-891902206
2021-08-03 11:27:55 -04:00
dist/build/uBlock0.chromium: tools/make-chromium.sh $(sources) $(platform) $(assets)
Add Makefile (#3789)
2021-07-31 18:11:28 +05:30
tools/make-chromium.sh
# Build the extension for Chromium.
chromium: dist/build/uBlock0.chromium
Add `opera` as a make target
2023-01-01 10:21:54 -05:00
dist/build/uBlock0.opera: tools/make-opera.sh $(sources) $(platform) $(assets)
tools/make-opera.sh
# Build the extension for Opera.
opera: dist/build/uBlock0.opera
Add build script as a dependency Related discussion: - https://github.com/gorhill/uBlock/pull/3789#issuecomment-891902206
2021-08-03 11:27:55 -04:00
dist/build/uBlock0.firefox: tools/make-firefox.sh $(sources) $(platform) $(assets)
Add Makefile (#3789)
2021-07-31 18:11:28 +05:30
tools/make-firefox.sh all
# Build the extension for Firefox.
firefox: dist/build/uBlock0.firefox
Add support for nodejs flavors The main nodejs flavor is "npm", which is to be used to lint/test and the publication of an official npm package -- and by design it has dependencies on mocha, eslint, etc. A new flavor "dig" has been created with minimal dependencies and which purpose is to easily allow to write specialized code to investigate local code changes in uBO -- and it's not meant for publication. Consequently, "make nodejs" has been replaced with "make npm", and a new "dig" target has been added to the makefile, to be used for instrumenting local code changes for investigation purpose.
2021-08-15 10:43:36 -04:00
dist/build/uBlock0.npm: tools/make-nodejs.sh $(sources) $(platform) $(assets)
tools/make-npm.sh
Add Makefile (#3789)
2021-07-31 18:11:28 +05:30
Fix makefile
2025-01-11 10:53:36 -05:00
npm: dist/build/uBlock0.npm
Better integrate latest eslint version
2025-01-09 09:33:22 -05:00
# Dev tools
Fix workflow and makefile
2025-01-10 11:08:54 -05:00
node_modules:
Better integrate latest eslint version
2025-01-09 09:33:22 -05:00
npm install
Add Makefile (#3789)
2021-07-31 18:11:28 +05:30
Fix makefile
2025-01-11 10:53:36 -05:00
init: node_modules
Fix workflow and makefile
2025-01-10 11:08:54 -05:00
Fix makefile
2025-01-11 10:53:36 -05:00
lint: init
Better integrate latest eslint version
2025-01-09 09:33:22 -05:00
npm run lint
Move linting out of tools/make-nodejs.sh (#3803)
2021-08-05 00:10:20 +05:30
Add support for nodejs flavors The main nodejs flavor is "npm", which is to be used to lint/test and the publication of an official npm package -- and by design it has dependencies on mocha, eslint, etc. A new flavor "dig" has been created with minimal dependencies and which purpose is to easily allow to write specialized code to investigate local code changes in uBO -- and it's not meant for publication. Consequently, "make nodejs" has been replaced with "make npm", and a new "dig" target has been added to the makefile, to be used for instrumenting local code changes for investigation purpose.
2021-08-15 10:43:36 -04:00
dist/build/uBlock0.dig: tools/make-nodejs.sh $(sources) $(platform) $(assets)
tools/make-dig.sh
dig: dist/build/uBlock0.dig
Add platform "dig", to experiment/validate code changes This is a replacement for the dubious approach when the extension itself was used to run benchmarks to detect performance and filtering behavior regressions.
2021-08-15 15:47:40 -04:00
cd dist/build/uBlock0.dig && npm install
dig-snfe: dig
cd dist/build/uBlock0.dig && npm run snfe $(run_options)
Add test target to makefile (#3810)
2021-08-10 23:20:06 +05:30
Rebuild MV3 extension if mv3-data content changes
2025-03-10 09:24:26 -04:00
dist/build/mv3-data:
Fix makefile
2025-03-09 08:41:28 -04:00
mkdir -p dist/build/mv3-data
Fix mv3 build commands
2025-03-08 13:39:53 -05:00
[mv3] Add support for custom DNR rules This feature is hidden behind the "Developer mode" setting in the dashboard. When "Developer mode" is enabled, a tab named "Develop" will become available in the dashboard. This tab is meant to contain tools for technical users. At the moment, the "Develop" pane allows to create custom DNR rules through a (CodeMirror-based) editor. For the sake of convenience, the DNR rule must be entered in YAML-like format. The format is not really full compliant YAML, just YAML-like, and very strict in order to ensure the parser stays simple enough. Lines starting with `#` are comments and will be ignored by the parser. Any line which do not match the parser's expectation will be marked as invalid, and the whole DNR rule containing such invalid lines will be discarded. There must not be empty lines inside a rule definition. Each DNR rule must be separated with a `---` line, which is known as a YAML document separator. String values must not be quoted, otherwise the quotes will be considered part of the value. There is one exception: `''` will be parsed as "an empty string". The editor will attempt to auto-complete known DNR keywords. That feature will improve over time. Though the parser will identify some errors, not all invalid DNR rules are currently identified by the parser, and these will be reported when the rules are registered through the DNR API. Better identifying invalid DNR rules at edit time will improve over time. The editor will report `regexFilter` values which are not supported by the DNR engine on the current platform. The editor reacts to instances of `regexFilter: ...` to report whether a regex value is supported. This means you can test for a regex value by using `# regexFilter: ...` so that you do not have to create an actual DNR rules just for the sake of testing. Custom DNR rules can be exported into a JSON file (a format known by the DNR API as a "static ruleset"). JSON-based ruleset can be imported, the content will be converted to YAML-like syntax. The editor will attempt to convert to YAML pasted content which can be JSON-parsed. It's possible to paste partially or wholly JSON-based rulesets. When disabling "Developer mode", all custom DNR rules will be unregistered from the DNR API. The DNR rules content will be left intact in such case. Existing DNR rules will be registered into the DNR API when re-enabling "Developer mode". Administrators can prevent "Developer mode" from being enabled by adding `develop` token to `disabledFeatures` setting. Related discussion: https://github.com/uBlockOrigin/uBOL-home/discussions/323 The main motivation is to give list maintainers a tool to assist with resolving filter issues. Custom DNR rules can assist in crafting and validating filters meant to work with uBOL. A secondary motivation is to provide technical users the ability to further customize their content blocker. More conveniences will be added over time, this is a first version.
2025-05-29 09:06:02 -04:00
ubol-codemirror:
$(MAKE) -sC platform/mv3/extension/lib/codemirror/codemirror-ubol/ ubol.bundle
Fix makefile
2025-05-05 08:37:26 -04:00
dist/build/uBOLite.chromium: tools/make-mv3.sh $(mv3-sources) $(platform) $(mv3-data) dist/build/mv3-data
Create a MVP version of uBOLite for Firefox What does not work at the time of commit: Cosmetic filtering does not work: The content scripts responsible for cosmetic filtering fail when trying to inject the stylesheets through document.adoptedStyleSheets, with the following error message: XrayWrapper denied access to property Symbol.iterator (reason: object is not safely Xrayable). See https://developer.mozilla.org/en-US/docs/Xray_vision for more information. ... css-declarative.js:106:8 A possible solution is to inject those content scripts in the MAIN world. However Firefox scripting API does not support MAIN world injection at the moment. Scriptlet-filtering does not work: Because scriptlet code needs to be injected in the MAIN world, and this is currently not supported by Firefox's scripting API, see https://bugzilla.mozilla.org/show_bug.cgi?id=1736575 There is no count badge on the toolbar icon in Firefox, as it currently does not support the `DNR.setExtensionActionOptions` method. Other than the above issues, it does appear uBO is blocking properly with no error reported in the dev console. The adoptedStyleSheets issue though is worrisome, as the cosmetic filtering content scripts were designed with ISOLATED world injection in mind. Being forced to inject in MAIN world (when available) make things a bit more complicated as uBO has to ensure it's global variables do not leak into the page.
2023-04-07 10:19:43 -04:00
tools/make-mv3.sh chromium
[mv3] Add support for custom DNR rules This feature is hidden behind the "Developer mode" setting in the dashboard. When "Developer mode" is enabled, a tab named "Develop" will become available in the dashboard. This tab is meant to contain tools for technical users. At the moment, the "Develop" pane allows to create custom DNR rules through a (CodeMirror-based) editor. For the sake of convenience, the DNR rule must be entered in YAML-like format. The format is not really full compliant YAML, just YAML-like, and very strict in order to ensure the parser stays simple enough. Lines starting with `#` are comments and will be ignored by the parser. Any line which do not match the parser's expectation will be marked as invalid, and the whole DNR rule containing such invalid lines will be discarded. There must not be empty lines inside a rule definition. Each DNR rule must be separated with a `---` line, which is known as a YAML document separator. String values must not be quoted, otherwise the quotes will be considered part of the value. There is one exception: `''` will be parsed as "an empty string". The editor will attempt to auto-complete known DNR keywords. That feature will improve over time. Though the parser will identify some errors, not all invalid DNR rules are currently identified by the parser, and these will be reported when the rules are registered through the DNR API. Better identifying invalid DNR rules at edit time will improve over time. The editor will report `regexFilter` values which are not supported by the DNR engine on the current platform. The editor reacts to instances of `regexFilter: ...` to report whether a regex value is supported. This means you can test for a regex value by using `# regexFilter: ...` so that you do not have to create an actual DNR rules just for the sake of testing. Custom DNR rules can be exported into a JSON file (a format known by the DNR API as a "static ruleset"). JSON-based ruleset can be imported, the content will be converted to YAML-like syntax. The editor will attempt to convert to YAML pasted content which can be JSON-parsed. It's possible to paste partially or wholly JSON-based rulesets. When disabling "Developer mode", all custom DNR rules will be unregistered from the DNR API. The DNR rules content will be left intact in such case. Existing DNR rules will be registered into the DNR API when re-enabling "Developer mode". Administrators can prevent "Developer mode" from being enabled by adding `develop` token to `disabledFeatures` setting. Related discussion: https://github.com/uBlockOrigin/uBOL-home/discussions/323 The main motivation is to give list maintainers a tool to assist with resolving filter issues. Custom DNR rules can assist in crafting and validating filters meant to work with uBOL. A secondary motivation is to provide technical users the ability to further customize their content blocker. More conveniences will be added over time, this is a first version.
2025-05-29 09:06:02 -04:00
mv3-chromium: ubol-codemirror dist/build/uBOLite.chromium
[mv3] Add support to add/remove rulesets through policies Related discussion: https://github.com/uBlockOrigin/uBOL-home/discussions/35#discussioncomment-11157444 New policy setting: `rulesets` Type: array Type of array items: string Each item in the list is a list id (as seen in `rulesets/ruleset-details.json`), prefixed with either `+` to enable the ruleset, or `-` to disable the ruleset. Users will not be able to enable or disable rulesets present in the `rulesets` policy. Disabled rulesets will not appear in the dashboard. Use `-*` to remove all non-default rulesets, except for those added using `+[ruleset_id]`. Additionally, some work has been done to properly handle policy changes in a non-blocking and deferred manner, as I observed that it often takes long for calls to `storage.manage.get` to resolve. This potentailly takes care of the following issue: https://github.com/uBlockOrigin/uBOL-home/issues/174
2024-11-11 13:20:54 -05:00
Fix makefile
2025-05-05 08:37:26 -04:00
dist/build/uBOLite.firefox: tools/make-mv3.sh $(mv3-sources) $(platform) $(mv3-data) dist/build/mv3-data
Create a MVP version of uBOLite for Firefox What does not work at the time of commit: Cosmetic filtering does not work: The content scripts responsible for cosmetic filtering fail when trying to inject the stylesheets through document.adoptedStyleSheets, with the following error message: XrayWrapper denied access to property Symbol.iterator (reason: object is not safely Xrayable). See https://developer.mozilla.org/en-US/docs/Xray_vision for more information. ... css-declarative.js:106:8 A possible solution is to inject those content scripts in the MAIN world. However Firefox scripting API does not support MAIN world injection at the moment. Scriptlet-filtering does not work: Because scriptlet code needs to be injected in the MAIN world, and this is currently not supported by Firefox's scripting API, see https://bugzilla.mozilla.org/show_bug.cgi?id=1736575 There is no count badge on the toolbar icon in Firefox, as it currently does not support the `DNR.setExtensionActionOptions` method. Other than the above issues, it does appear uBO is blocking properly with no error reported in the dev console. The adoptedStyleSheets issue though is worrisome, as the cosmetic filtering content scripts were designed with ISOLATED world injection in mind. Being forced to inject in MAIN world (when available) make things a bit more complicated as uBO has to ensure it's global variables do not leak into the page.
2023-04-07 10:19:43 -04:00
tools/make-mv3.sh firefox
Add experimental mv3 version This create a separate Chromium extension, named "uBO Minus (MV3)". This experimental mv3 version supports only the blocking of network requests through the declarativeNetRequest API, so as to abide by the stated MV3 philosophy of not requiring broad "read/modify data" permission. Accordingly, the extension should not trigger the warning at installation time: Read and change all your data on all websites The consequences of being permission-less are the following: - No cosmetic filtering (##) - No scriptlet injection (##+js) - No redirect= filters - No csp= filters - No removeparam= filters At this point there is no popup panel or options pages. The default filterset correspond to the default filterset of uBO proper: Listset for 'default': https://ublockorigin.github.io/uAssets/filters/badware.txt https://ublockorigin.github.io/uAssets/filters/filters.txt https://ublockorigin.github.io/uAssets/filters/filters-2020.txt https://ublockorigin.github.io/uAssets/filters/filters-2021.txt https://ublockorigin.github.io/uAssets/filters/filters-2022.txt https://ublockorigin.github.io/uAssets/filters/privacy.txt https://ublockorigin.github.io/uAssets/filters/quick-fixes.txt https://ublockorigin.github.io/uAssets/filters/resource-abuse.txt https://ublockorigin.github.io/uAssets/filters/unbreak.txt https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easyprivacy.txt https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext The result of the conversion of the filters in all these filter lists is as follow: Ruleset size for 'default': 22245 Good: 21408 Maybe good (regexes): 127 redirect-rule= (discarded): 458 csp= (discarded): 85 removeparams= (discarded): 22 Unsupported: 145 The fact that the number of DNR rules are far lower than the number of network filters reported in uBO comes from the fact that lists-to-rulesets converter does its best to coallesce filters into minimal set of rules. Notably, the DNR's requestDomains condition property allows to create a single DNR rule out of all pure hostname-based filters. Regex-based rules are dynamically added at launch time since they must be validated as valid DNR regexes through isRegexSupported() API call. At this point I consider being permission-less the limiting factor: if broad "read/modify data" permission is to be used, than there is not much point for an MV3 version over MV2, just use the MV2 version if you want to benefit all the features which can't be implemented without broad "read/modify data" permission. To locally build the MV3 extension: make mv3 Then load the resulting extension directory in the browser using the "Load unpacked" button. From now on there will be a uBlock0.mv3.zip package available in each release.
2022-09-06 13:47:52 -04:00
[mv3] Add support for custom DNR rules This feature is hidden behind the "Developer mode" setting in the dashboard. When "Developer mode" is enabled, a tab named "Develop" will become available in the dashboard. This tab is meant to contain tools for technical users. At the moment, the "Develop" pane allows to create custom DNR rules through a (CodeMirror-based) editor. For the sake of convenience, the DNR rule must be entered in YAML-like format. The format is not really full compliant YAML, just YAML-like, and very strict in order to ensure the parser stays simple enough. Lines starting with `#` are comments and will be ignored by the parser. Any line which do not match the parser's expectation will be marked as invalid, and the whole DNR rule containing such invalid lines will be discarded. There must not be empty lines inside a rule definition. Each DNR rule must be separated with a `---` line, which is known as a YAML document separator. String values must not be quoted, otherwise the quotes will be considered part of the value. There is one exception: `''` will be parsed as "an empty string". The editor will attempt to auto-complete known DNR keywords. That feature will improve over time. Though the parser will identify some errors, not all invalid DNR rules are currently identified by the parser, and these will be reported when the rules are registered through the DNR API. Better identifying invalid DNR rules at edit time will improve over time. The editor will report `regexFilter` values which are not supported by the DNR engine on the current platform. The editor reacts to instances of `regexFilter: ...` to report whether a regex value is supported. This means you can test for a regex value by using `# regexFilter: ...` so that you do not have to create an actual DNR rules just for the sake of testing. Custom DNR rules can be exported into a JSON file (a format known by the DNR API as a "static ruleset"). JSON-based ruleset can be imported, the content will be converted to YAML-like syntax. The editor will attempt to convert to YAML pasted content which can be JSON-parsed. It's possible to paste partially or wholly JSON-based rulesets. When disabling "Developer mode", all custom DNR rules will be unregistered from the DNR API. The DNR rules content will be left intact in such case. Existing DNR rules will be registered into the DNR API when re-enabling "Developer mode". Administrators can prevent "Developer mode" from being enabled by adding `develop` token to `disabledFeatures` setting. Related discussion: https://github.com/uBlockOrigin/uBOL-home/discussions/323 The main motivation is to give list maintainers a tool to assist with resolving filter issues. Custom DNR rules can assist in crafting and validating filters meant to work with uBOL. A secondary motivation is to provide technical users the ability to further customize their content blocker. More conveniences will be added over time, this is a first version.
2025-05-29 09:06:02 -04:00
mv3-firefox: ubol-codemirror dist/build/uBOLite.firefox
[mv3] Add support to add/remove rulesets through policies Related discussion: https://github.com/uBlockOrigin/uBOL-home/discussions/35#discussioncomment-11157444 New policy setting: `rulesets` Type: array Type of array items: string Each item in the list is a list id (as seen in `rulesets/ruleset-details.json`), prefixed with either `+` to enable the ruleset, or `-` to disable the ruleset. Users will not be able to enable or disable rulesets present in the `rulesets` policy. Disabled rulesets will not appear in the dashboard. Use `-*` to remove all non-default rulesets, except for those added using `+[ruleset_id]`. Additionally, some work has been done to properly handle policy changes in a non-blocking and deferred manner, as I observed that it often takes long for calls to `storage.manage.get` to resolve. This potentailly takes care of the following issue: https://github.com/uBlockOrigin/uBOL-home/issues/174
2024-11-11 13:20:54 -05:00
[mv3] Safari works; use 3-component version for uBOL uBOL doesn't pass validation when using 4-component versioning, so falling back to 3-component versioning for all platforms to avoid special case.
2025-05-08 16:53:07 -04:00
dist/build/uBOLite.edge: tools/make-mv3.sh $(mv3-sources) $(mv3-edge-deps) $(mv3-data) dist/build/mv3-data
Use "make mv3-edge" to build Edge package
2025-03-08 10:43:59 -05:00
tools/make-mv3.sh edge
[mv3] Add ability to enable/disable filter lists
2022-09-13 17:44:24 -04:00
[mv3] Add support for custom DNR rules This feature is hidden behind the "Developer mode" setting in the dashboard. When "Developer mode" is enabled, a tab named "Develop" will become available in the dashboard. This tab is meant to contain tools for technical users. At the moment, the "Develop" pane allows to create custom DNR rules through a (CodeMirror-based) editor. For the sake of convenience, the DNR rule must be entered in YAML-like format. The format is not really full compliant YAML, just YAML-like, and very strict in order to ensure the parser stays simple enough. Lines starting with `#` are comments and will be ignored by the parser. Any line which do not match the parser's expectation will be marked as invalid, and the whole DNR rule containing such invalid lines will be discarded. There must not be empty lines inside a rule definition. Each DNR rule must be separated with a `---` line, which is known as a YAML document separator. String values must not be quoted, otherwise the quotes will be considered part of the value. There is one exception: `''` will be parsed as "an empty string". The editor will attempt to auto-complete known DNR keywords. That feature will improve over time. Though the parser will identify some errors, not all invalid DNR rules are currently identified by the parser, and these will be reported when the rules are registered through the DNR API. Better identifying invalid DNR rules at edit time will improve over time. The editor will report `regexFilter` values which are not supported by the DNR engine on the current platform. The editor reacts to instances of `regexFilter: ...` to report whether a regex value is supported. This means you can test for a regex value by using `# regexFilter: ...` so that you do not have to create an actual DNR rules just for the sake of testing. Custom DNR rules can be exported into a JSON file (a format known by the DNR API as a "static ruleset"). JSON-based ruleset can be imported, the content will be converted to YAML-like syntax. The editor will attempt to convert to YAML pasted content which can be JSON-parsed. It's possible to paste partially or wholly JSON-based rulesets. When disabling "Developer mode", all custom DNR rules will be unregistered from the DNR API. The DNR rules content will be left intact in such case. Existing DNR rules will be registered into the DNR API when re-enabling "Developer mode". Administrators can prevent "Developer mode" from being enabled by adding `develop` token to `disabledFeatures` setting. Related discussion: https://github.com/uBlockOrigin/uBOL-home/discussions/323 The main motivation is to give list maintainers a tool to assist with resolving filter issues. Custom DNR rules can assist in crafting and validating filters meant to work with uBOL. A secondary motivation is to provide technical users the ability to further customize their content blocker. More conveniences will be added over time, this is a first version.
2025-05-29 09:06:02 -04:00
mv3-edge: ubol-codemirror dist/build/uBOLite.edge
Add experimental mv3 version This create a separate Chromium extension, named "uBO Minus (MV3)". This experimental mv3 version supports only the blocking of network requests through the declarativeNetRequest API, so as to abide by the stated MV3 philosophy of not requiring broad "read/modify data" permission. Accordingly, the extension should not trigger the warning at installation time: Read and change all your data on all websites The consequences of being permission-less are the following: - No cosmetic filtering (##) - No scriptlet injection (##+js) - No redirect= filters - No csp= filters - No removeparam= filters At this point there is no popup panel or options pages. The default filterset correspond to the default filterset of uBO proper: Listset for 'default': https://ublockorigin.github.io/uAssets/filters/badware.txt https://ublockorigin.github.io/uAssets/filters/filters.txt https://ublockorigin.github.io/uAssets/filters/filters-2020.txt https://ublockorigin.github.io/uAssets/filters/filters-2021.txt https://ublockorigin.github.io/uAssets/filters/filters-2022.txt https://ublockorigin.github.io/uAssets/filters/privacy.txt https://ublockorigin.github.io/uAssets/filters/quick-fixes.txt https://ublockorigin.github.io/uAssets/filters/resource-abuse.txt https://ublockorigin.github.io/uAssets/filters/unbreak.txt https://easylist.to/easylist/easylist.txt https://easylist.to/easylist/easyprivacy.txt https://malware-filter.gitlab.io/malware-filter/urlhaus-filter-online.txt https://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1&mimetype=plaintext The result of the conversion of the filters in all these filter lists is as follow: Ruleset size for 'default': 22245 Good: 21408 Maybe good (regexes): 127 redirect-rule= (discarded): 458 csp= (discarded): 85 removeparams= (discarded): 22 Unsupported: 145 The fact that the number of DNR rules are far lower than the number of network filters reported in uBO comes from the fact that lists-to-rulesets converter does its best to coallesce filters into minimal set of rules. Notably, the DNR's requestDomains condition property allows to create a single DNR rule out of all pure hostname-based filters. Regex-based rules are dynamically added at launch time since they must be validated as valid DNR regexes through isRegexSupported() API call. At this point I consider being permission-less the limiting factor: if broad "read/modify data" permission is to be used, than there is not much point for an MV3 version over MV2, just use the MV2 version if you want to benefit all the features which can't be implemented without broad "read/modify data" permission. To locally build the MV3 extension: make mv3 Then load the resulting extension directory in the browser using the "Load unpacked" button. From now on there will be a uBlock0.mv3.zip package available in each release.
2022-09-06 13:47:52 -04:00
Fix makefile
2025-05-05 08:37:26 -04:00
dist/build/uBOLite.safari: tools/make-mv3.sh $(mv3-sources) $(mv3-safari-deps) $(mv3-data) dist/build/mv3-data
[mv3] Merge Safari branch Safari version of uBO Lite can now be built from master branch. Related issue: https://github.com/uBlockOrigin/uBOL-home/issues/327
2025-04-19 13:08:59 -04:00
tools/make-mv3.sh safari
[mv3] Add support for custom DNR rules This feature is hidden behind the "Developer mode" setting in the dashboard. When "Developer mode" is enabled, a tab named "Develop" will become available in the dashboard. This tab is meant to contain tools for technical users. At the moment, the "Develop" pane allows to create custom DNR rules through a (CodeMirror-based) editor. For the sake of convenience, the DNR rule must be entered in YAML-like format. The format is not really full compliant YAML, just YAML-like, and very strict in order to ensure the parser stays simple enough. Lines starting with `#` are comments and will be ignored by the parser. Any line which do not match the parser's expectation will be marked as invalid, and the whole DNR rule containing such invalid lines will be discarded. There must not be empty lines inside a rule definition. Each DNR rule must be separated with a `---` line, which is known as a YAML document separator. String values must not be quoted, otherwise the quotes will be considered part of the value. There is one exception: `''` will be parsed as "an empty string". The editor will attempt to auto-complete known DNR keywords. That feature will improve over time. Though the parser will identify some errors, not all invalid DNR rules are currently identified by the parser, and these will be reported when the rules are registered through the DNR API. Better identifying invalid DNR rules at edit time will improve over time. The editor will report `regexFilter` values which are not supported by the DNR engine on the current platform. The editor reacts to instances of `regexFilter: ...` to report whether a regex value is supported. This means you can test for a regex value by using `# regexFilter: ...` so that you do not have to create an actual DNR rules just for the sake of testing. Custom DNR rules can be exported into a JSON file (a format known by the DNR API as a "static ruleset"). JSON-based ruleset can be imported, the content will be converted to YAML-like syntax. The editor will attempt to convert to YAML pasted content which can be JSON-parsed. It's possible to paste partially or wholly JSON-based rulesets. When disabling "Developer mode", all custom DNR rules will be unregistered from the DNR API. The DNR rules content will be left intact in such case. Existing DNR rules will be registered into the DNR API when re-enabling "Developer mode". Administrators can prevent "Developer mode" from being enabled by adding `develop` token to `disabledFeatures` setting. Related discussion: https://github.com/uBlockOrigin/uBOL-home/discussions/323 The main motivation is to give list maintainers a tool to assist with resolving filter issues. Custom DNR rules can assist in crafting and validating filters meant to work with uBOL. A secondary motivation is to provide technical users the ability to further customize their content blocker. More conveniences will be added over time, this is a first version.
2025-05-29 09:06:02 -04:00
mv3-safari: ubol-codemirror dist/build/uBOLite.safari
[mv3] Merge Safari branch Safari version of uBO Lite can now be built from master branch. Related issue: https://github.com/uBlockOrigin/uBOL-home/issues/327
2025-04-19 13:08:59 -04:00
Use `git clone` instead of submodule to pull uAssets dependencies Related issue: - https://github.com/uBlockOrigin/uBlock-issues/issues/2358 We need two different branches of uAssets to properly add the default filter lists into the packages. I couldn't figure out how to do this with submodules, using simple `git clone` as a dependency just work.
2022-11-14 09:50:53 -05:00
dist/build/uAssets:
tools/pull-assets.sh
Add update-submodules as a target
2021-07-31 14:50:31 -04:00
Add Makefile (#3789)
2021-07-31 18:11:28 +05:30
clean:
Fix workflow and makefile
2025-01-10 11:08:54 -05:00
rm -rf dist/build tmp/node_modules node_modules
Add platform "dig", to experiment/validate code changes This is a replacement for the dubious approach when the extension itself was used to run benchmarks to detect performance and filtering behavior regressions.
2021-08-15 15:47:40 -04:00
Add ability to clean dist/build/[assets-related folders]
2024-02-25 18:27:07 -05:00
cleanassets:
rm -rf dist/build/mv3-data dist/build/uAssets
Add platform "dig", to experiment/validate code changes This is a replacement for the dubious approach when the extension itself was used to run benchmarks to detect performance and filtering behavior regressions.
2021-08-15 15:47:40 -04:00
Update makefile
2025-09-04 09:51:02 -04:00
# Usage: make publish-publish version=?
Improve publish scripts
2025-08-25 15:10:36 -04:00
publish-chromium:
Update makefile
2025-09-04 09:51:02 -04:00
node publish-extension/publish-chromium.js \
ghowner=gorhill \
ghrepo=uBlock \
ghtag=$(version) \
ghasset=chromium \
storeid=cjpalhdlnbpafiamejdnhcphjbkeiagm
# Usage: make publish-edge version=?
Improve publish scripts
2025-08-25 15:10:36 -04:00
publish-edge:
Update makefile
2025-09-04 09:51:02 -04:00
node publish-extension/publish-edge.js \
ghowner=gorhill \
ghrepo=uBlock \
ghtag=$(version) \
ghasset=chromium \
datebasedmajor=1 \
storeid=odfafepnkmbhccpbejgmiehpchacaeak \
Unreference obsolete npm scripts Related issue: https://github.com/uBlockOrigin/uBlock-issues/issues/3805
2025-09-20 09:21:14 -04:00
productid=$(shell secret-tool lookup token ubo_edge_id)
Update makefile
2025-09-04 09:51:02 -04:00
# Usage: make publish-firefox version=?
publish-firefox:
node publish-extension/publish-firefox.js \
ghowner=gorhill \
ghrepo=uBlock \
ghtag=$(version) \
ghasset=firefox \
storeid=uBlock0@raymondhill.net \
channel=listed
# Usage: make publish-dev-chromium version=?
publish-dev-chromium:
node publish-extension/publish-chromium.js \
ghowner=gorhill \
ghrepo=uBlock \
ghtag=$(version) \
ghasset=chromium \
storeid=cgbcahbpdhpcegmbfconppldiemgcoii
# Usage: make publish-dev-firefox version=?
publish-dev-firefox:
node publish-extension/publish-firefox.js \
ghowner=gorhill \
ghrepo=uBlock \
ghtag=$(version) \
ghasset=firefox \
storeid=uBlock0@raymondhill.net \
channel=unlisted \
Fix makefile
2025-09-06 10:22:45 -04:00
updatepath=./dist/firefox/updates.json
Update makefile
2025-09-04 09:51:02 -04:00
# Usage: make upload-firefox version=?
upload-firefox:
node publish-extension/upload-firefox.js \
ghowner=gorhill \
ghrepo=uBlock \
ghtag=$(version) \
ghasset=firefox \
storeid=uBlock0@raymondhill.net \
channel=listed
# Usage: make upload-dev-firefox version=?
upload-dev-firefox:
node publish-extension/upload-firefox.js \
ghowner=gorhill \
ghrepo=uBlock \
ghtag=$(version) \
ghasset=firefox \
storeid=uBlock0@raymondhill.net \
channel=unlisted \
Fix makefile
2025-09-06 10:22:45 -04:00
updatepath=./dist/firefox/updates.json
Improve publish scripts
2025-08-25 15:10:36 -04:00
Add platform "dig", to experiment/validate code changes This is a replacement for the dubious approach when the extension itself was used to run benchmarks to detect performance and filtering behavior regressions.
2021-08-15 15:47:40 -04:00
# Not real targets, just convenient for auto-completion at shell prompt
compare:
@echo
maxcost:
@echo
Add median cost output to dig-snfe
2021-08-29 08:58:20 -04:00
medcost:
@echo
Add platform "dig", to experiment/validate code changes This is a replacement for the dubious approach when the extension itself was used to run benchmarks to detect performance and filtering behavior regressions.
2021-08-15 15:47:40 -04:00
mincost:
@echo
Expose matchAndFetchModifiers() in npm package Also, add instrumentation for the method in dig-snfe.
2021-08-17 12:48:39 -04:00
modifiers:
@echo
Add platform "dig", to experiment/validate code changes This is a replacement for the dubious approach when the extension itself was used to run benchmarks to detect performance and filtering behavior regressions.
2021-08-15 15:47:40 -04:00
record:
@echo
wasm:
@echo
Copy Permalink