Question: [webView_flutter] screen blank on some Huawei devices with Flutter 3.29?

I've landed some changes to master that changes how we do selection of platform views and rendering backend choice on mediatek devices that I believe should fix these issues.

[webView_flutter] screen blank on some Huawei devices with Flutter 3.29
### Steps to reproduce

1.Create a new Flutter project with WebView:
flutter create webview_test
cd webview_test
flutter pub add webview_flutter

2.Edit main.dart to include a simple WebView

dart
import 'package:flutter/material.dart';
import 'package:webview_flutter/webview_flutter.dart';

void main() {
 runApp(MyApp());
}

class MyApp extends StatefulWidget {
 @override
 _MyAppState createState() => _MyAppState();
}

class _MyAppState extends State {
 late final WebViewController _controller;

 @override
 void initState() {
 super.initState();
 _controller = WebViewController()
 ..loadRequest(Uri.parse(' URL
 }

 @override
 Widget build(BuildContext context) {
 return MaterialApp(
 home: Scaffold(
 appBar: AppBar(title: Text("WebView Test")),
 body: WebViewWidget(controller: _controller),
 ),
 );
 }
}

3.Execute flutter run

### Expected results

The web page ( URL should display correctly in the WebView.
The user must be able to interact with the page (scroll, clicks, etc.).

### Actual results

On some Huawei devices ( y8p, y9s, p30 pro, p40 pro ..) :

-The WebView screen stay blank.
-Sometimes the application crashes immediately when opening the WebView.

### Code sample

(The code provided in the "Steps to reproduce" section can be used as a minimal, reproducible example.)

### Screenshots or Video

 Screenshots / Video demonstration

[Upload media here]

### Logs

 Logs

console
[Paste your logs here]

### Flutter Doctor output

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.27.3, on Microsoft Windows [version 10.0.26100.3194], locale fr-FR)
[✓] Windows Version (Installed version of Windows is version 10 or higher)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Chrome - develop for the web
[✗] Visual Studio - develop Windows apps
 ✗ Visual Studio not installed; this is necessary to develop Windows apps.
 Download at URL
 Please install the "Desktop development with C++" workload, including all of its default components
[✓] Android Studio (version 2022.3)
[!] Android Studio (version 2024.2)
 ✗ Unable to determine bundled Java version.
[✓] Connected device (3 available)
[✓] Network resources

Hi @Bouchka99, Thanks for filing the issue. Can you share more details about the device (Android version) and the output that you are seeing?

Looks similar to URL

@maheshj01 Hello,
Thanks for your response. In fact, I notice the problem especially on Huawei devices that probably don't have Google services (though I can't be sure if it's related). For example, on Android 10 with the Huawei P40 Pro:

Android Version: 10 (EMUI 10.1)

@Bouchka99 Please share the visual output (Screenshot/recording) that you are seeing along with the output of `flutter run -v`

@maheshj01 Hi, i'm facing the same issue and could provide a video i've got from one of our customers. I can send you a link via email if you like, but i can't do that in public.

But i can't provide the output of `flutter run -v` for that device as its just a video i got sent from one of the users.

Flutter_Webview not working on API 30 or lower after latest upgrade of flutter
### Steps to reproduce

Issue: WebView Not Displaying Content on Android API 30 or Lower After Flutter Upgrade

Description

After upgrading Flutter to the latest version, the WebView (webview_flutter package) is not displaying any content on Android devices running API 30 or lower. Instead of rendering the web content, the WebView shows a blank screen. This issue does not occur on iOS devices or Android devices with API 32
 and above.

Steps to Reproduce

1. Upgrade Flutter to the latest version:

flutter upgrade

2. Ensure that the webview_flutter package is updated in pubspec.yaml:

dependencies:
 webview_flutter: ^latest_version

3. Run the app on an Android device with API 30 or lower.

4. Load a WebView in your app and observe the behavior.

Expected Behavior

The WebView should load and display web content on all devices, including those with API 30 and lower.

Actual Behavior

On Android devices with API 30 or lower, the WebView results in a blank screen, and no content is displayed.

Environment

Flutter Version: X.X.X (Replace with actual version)

Dart Version: X.X.X

webview_flutter Version: X.X.X

Android API Level: 30 or lower

Device/Emulator: (Specify if tested on physical device or emulator)

Possible Causes

Recent changes in Flutter or WebView dependencies that affect compatibility with lower Android APIs.

Issues with Android WebView updates in API 30 or below.

Incorrect or missing configuration for WebView in AndroidManifest.xml.

Workarounds Tried

Updating to the latest WebView package version.

Modifying Android manifest to allow cleartext traffic.

Using an older version of the WebView package for compatibility.

Logs & Errors

(Include any relevant logs from flutter run or adb logcat)

Temporary Solution (if any)

(Provide any workarounds that were found, if applicable.)

References & Related Issues

(Include any related GitHub issues or forum discussions.)

Please help us resolve this issue for devices running Android API 30 and lower.

### Expected results

Issue: WebView Not Displaying Content on Android API 30 or Lower After Flutter Upgrade

Description

After upgrading Flutter to the latest version, the WebView (webview_flutter package) is not displaying any content on Android devices running API 30 or lower. Instead of rendering the web content, the WebView shows a blank screen. This issue does not occur on iOS devices or Android devices with API 30 and above.

Steps to Reproduce

1. Upgrade Flutter to the latest version:

flutter upgrade

2. Ensure that the webview_flutter package is updated in pubspec.yaml:

dependencies:
 webview_flutter: ^latest_version

3. Run the app on an Android device with API 30 or lower.

4. Load a WebView in your app and observe the behavior.

Expected Behavior

The WebView should load and display web content on all devices, including those with API 30 and lower.

Actual Behavior

On Android devices with API 30 or lower, the WebView results in a blank screen, and no content is displayed.

Environment

Flutter Version: X.X.X (Replace with actual version)

Dart Version: X.X.X

webview_flutter Version: X.X.X

Android API Level: 30 or lower

Device/Emulator: (Specify if tested on physical device or emulator)

Possible Causes

Recent changes in Flutter or WebView dependencies that affect compatibility with lower Android APIs.

Issues with Android WebView updates in API 30 or below.

Incorrect or missing configuration for WebView in AndroidManifest.xml.

Workarounds Tried

Updating to the latest WebView package version.

Modifying Android manifest to allow cleartext traffic.

Using an older version of the WebView package for compatibility.

Logs & Errors

(Include any relevant logs from flutter run or adb logcat)

Temporary Solution (if any)

(Provide any workarounds that were found, if applicable.)

References & Related Issues

(Include any related GitHub issues or forum discussions.)

Please help us resolve this issue for devices running Android API 30 and lower.

### Actual results

Blank Screen

### Code sample

 Code sample

dart
[Paste your code here]

### Screenshots or Video

 Screenshots / Video demonstration

[Upload media here]

### Logs

 Logs

console
[Paste your logs here]

### Flutter Doctor output

 Doctor output

console
[Paste your output here]

Can you please include the phone model you are seeing this problem on? This is probably a device specific problem, and sounds similar to :

 URL
 URL
 URL

URL this one? Can you confirm its running Android 9.0. If so this is not similar to the other issues, as this device is having problems on the OpenGLES backend.

I was facing a similar issue as described in #160804, where the rendering was blank, and videos were only playing audio without displaying visuals. After following the suggestions here, I was able to fix the issue by disabling Impeller.

It worked like a charm! 🎉
Thank you so much @jonahwilliams

For now, disabling Impeller is the recommended workaround until the PR mentioned by Jonah (#163265) is merged into the main branch and included in a new Flutter release.

Hope this helps others facing the same problem! 🚀

Issue Description:
After upgrading Flutter, the WebView in your app stopped displaying content correctly on devices running Android API 30 or lower (like OPPO F11 with Android 11 and OPPO A15 with Android 10). Instead of showing the web content, the WebView displays a blank screen or becomes blurry with no rendered content.

However, this issue does not occur on devices with API 32 or higher (like Android 12L).

Steps Taken:
Flutter Upgrade: Upgraded Flutter to the latest version.
webview_flutter Update: The webview_flutter package was also updated to the latest version.
Device Testing: The issue was observed on OPPO F11 (Android 11, API 30) and OPPO A15 (Android 10, API 29), while WebView functions fine on devices with API 32 and above.
Temporary Workaround:
To fix the issue temporarily, I disabled Impeller as a rendering engine. This workaround was effective, but it's not ideal long-term because Impeller is being phased out.

Logs and Errors:
I tried updating the webview_flutter package and modifying your AndroidManifest.xml, but the issue persists. The behavior observed is similar to the one discussed in issue #160804, where rendering issues occurred due to a blank screen, and videos were playing audio without visuals.

Conclusion:
While the workaround is currently functional, the problem appears to be related to the interaction between Flutter, WebView, and certain Android versions, especially on devices with API 30 and lower. I'm seeking a permanent solution and asking for insights into how this can be fixed without relying on the Impeller workaround.

Additional Information:
Device Models: OPPO A15 (Android 10, API 29) and OPPO F11 (Android 11, API 30).
The issue is observed when the app is launched on these devices, with WebView failing to display content, and the display breaking or being blurry.

While that is a good workaround, we need information on how to fix the bug, because long term we plan to remove the ability to disable impeller

Thanks for the update, @jonahwilliams. I’m seeing the same issue on OPPO F11 (API 30) and OPPO A15 (API 29) with WebView and video playback. The Impeller workaround works temporarily, but I'd prefer a long-term solution since it doesn’t work on all devices, especially those with API 30 and lower. Is there an upcoming fix for this?

What's the expected release version that these changes will be included in?


Question: commit `Implement Quick Dungeons Select` seems to have broken the desktop version of `additionalvisualsettings`?

The scripts should update automatically and should also support new scripts, at least this is the design of it and how I made the client edit initially work, but then again ever since catchfilterfantasia got introduced, that has also been causing problems.

It's likely that the custom edit needs to be updated and needs to be looked at, but then again I haven't touched this or have been wanting to maintain this since January.

commit `Implement Quick Dungeons Select` seems to have broken the desktop version of `additionalvisualsettings`
ended up leaving a comment on the commit, but thought I should throw up an issue about it as well. Upon updating scripts, the latest version of `additionalvisualsettings` seems to be broken and no longer loading in the desktop version of the game.

If I go and put it in the `scripts` folder and change it back to the older version it seems to work again, but obviously I end up missing the reason for the update.

I'm just wondering if you are just no longer supporting the desktop version? as there are a couple scripts as of recent that just don't work in the desktop version at all.

Script that don't show up in desktop version are as followed:
additionalvisualsettings (broken within recent commit)
catchfilterfantasia
perkypokeruspandemic

I can confirm that there is problems with some newer scripts.

The last additionalvisualsettings is just broken. It doesn't load, OR it loads but other scripts don't. Seems to be random on every reload of the desktop app.

Some goes for catchfilterfantasia. Sometimes it just load alone, or 99% of the time it doesn't load at all. (and even before the last additionalvisualsettings update)

Also, perkypokeruspandemic seems to never load.

Haven't had the issue it loading but not other scripts loading for any of them, the ones I mentioned just outright refuse to load anymore.

From what I can tell it's something to do with a `var` to `const` change, because if I put them into the `scripts` folder and do a rename for every `const` to be `var` instead it works perfectly and loads, same with the other two scripts (changing all `const` to `var).

About where things are currently with Desktop support: URL (well thought I'd include this in for transparency)

As for the changes being mentioned, I suspect it's maybe the changes being done to the initialization portion (unable to test these myself atm and hadn't prior).

Try reverting just this portion of the script and keep the rest of the variable declaration (const & let) changes throughout the rest of the script:
image

If this is the issue I can revert it in the next revision being worked on at the moment, and changing this in a few other scripts where it may be problematic.

@Ephenia Yep that's exactly it from the looks of things, as reverting that portion back to the previous revision seems to make things work and load correctly, can also confirm that it changing that partion in the other scripts that I mentioned above works as well.

@Ephenia actually scratch that, it's causing other issues and idk why I didn't notice >.< for some reason or another it's now only loading a portion of the scripts. So many others just seem to disappear..

Going to test a bit more to see what is causing this new issue.

Okay after a bit more testing I have found these things:

doing the above does work correctly but there seems to be more changes needed in at least the `additionalvisualsettings` script, from what I can tell I needed to change the

let checkWildPokeName;
let checkWildPokeDefeat;
let checkWildPokeImg;
let checkWildPokeHealth;
let checkWildPokeCatch;
let checkAllNotification;
const notificFunc = Notifier.notify;
let newSave;
let trainerCards;

to be

var checkWildPokeName;
var checkWildPokeDefeat;
var checkWildPokeImg;
var checkWildPokeHealth;
var checkWildPokeCatch;
var checkAllNotification;
const notificFunc = Notifier.notify;
var newSave;
var trainerCards;

to actually make it work and stop the whole other scripts randomly disappearing act also seems that only needing to change the `const scriptName` and `const scriptElement` to be `var scriptName` and `var scriptElement` is what is needed for the loadscript function (from what I can tell)

oof I can't seem to test now as I'm now randomly getting this error for some reason >.<
06-29-2022_22-23-32

@Ephenia Okay back to normal, from my latest testings everything is now working correctly from the looks of it, other than `catchfilterfantasia` is the only one missing.

Loving all this information and all the testing that you're doing, you're a huge help and I really appreciate it as well as your time! I must say that you're great with providing quality testing. You're always free to hit me up personally too if you want by the way, if it would also be easier or more convenient.

Anyway, are you happening to load all of the scripts by the way?

@Ephenia it's not a problem at all, I try my best to test things and figure things out as I go along with issuing bug reports and such :p

Sounds good :D

as for loading all the scripts, the only one that seems to be missing/not loading currently on multiple refreshes is the `infiniteseasonalevents` script. Everything else seems to be at least loading correctly now for the most part from my multiple refreshes from what I can tell.

Maybe the simpleweatherchanger could be bugging it out or interfering with it, since it also had the slight change to initialization. But, if that isn't it, then loading the script standalone would definitely tell if the script itself is the issue, probably.

yea shit so confusing, because if I go to put `infiniteseasonalevents` script into the scripts folder to load it standalone, it then makes the `catchfilterfantasia` stop loading instead xD

You should be able to override all the scripts with blank ones with the same names and just have `infiniteseasonalevents` load, at least this should still be doable (I think) ;p

okay so did a little bit of testing with everything blanked out in scripts and then moving between these last 3 (infiniteseasonalevents/simpleweatherchanger/catchfilterfantasia) these are the things I noticed:

With `infiniteseasonalevents` and `simpleweatherchanger` being the only two that wasn't blanked out, they loaded fine, if I re-added `catchfilterfantasia` it stopped loading the `infiniteseasonalevents` but `simpleweatherchanger` would still load, blanking out `simpleweatherchanger` didn't seem to bring back `infiniteseasonalevents` however if I was do that, if I was to blank out `catchfilterfantasia` again `infiniteseasonalevents` would however load just fine again.

so from this bit of testing it seems to be something to do with `catchfilterfantasia` causing issues atm.

Hm... quite interesting...

I wonder if it has something to do with the use of `window`, which may be unfortunate if that's actually the case.

hmm yea that could possibly be it, sadly with how late it is getting here and the fact I sadly have to work in the morning I may need to call it a night on testing for now and come back to testing things again once I return from work tomorrow. I'll throw you an add on disc tomorrow once I'm around and we can see if we can figure things out.

Sent you a FR on discord, and should be around for most of the day.

Auto Hatchery stopped working on desktop on version 0.9.5
I play on the Windows desktop version. I haven't updated to 0.9.6, but auto hatchery has stopped working. The buttons show up, but no eggs are added to the hatchery. The Auto Fossil and Auto Egg features do work, though. I tried to restart the game, to enable and disable the script (with their respective restarts) and to overwrite the app.asar file, but none of these worked.

Which version of the auto hatchery script are you using ?
If you dont want to update, you will need to use a version before the commits on the 26th
 URL

The script version is 1.6, which seems to correspond with the latest version. Do these scripts update automatically? That would explain it. Is there a way to avoid this update process? Thank you very much!

V1.6 contains yesterday changes which were made for pokeclicker v0.9.6 and are unhappily not retroactive.
I do not know how the scripts work for windows and how they are updated so I am not of a great help here :(

I think I'll update to 0.9.7, since now the XP nerf isn't that bad, and everything should work ok. Thanks for taking the time of looking into it.


Question: Multiple Formbuilder Forms on a single page not working properly.

formRender does not have the promise interface, only multiple formBuilder instances need to be created via awaiting the promise interface.

Multiple Formbuilder Forms on a single page not working properly.
### Description: Two Formbuilder forms on a single page not working properly when clicking on the save button.

### Environment Details: I am working on a staging environment having PHP on the stack side

 - formBuilder Version: Latest one
 - Browser: Chrome
 - OS: Windows

### Expected Behavior: No matter how many formbuilder forms we use on a single page if the ids of that formbuilder form are different. Each action should work with respect to individual forms.

### Actual Behavior: Right now once I click on the save button of the first formbuilder form it throws some error "Uncaught TypeError: formBuilder.actions.getData is not a function"

### Steps to Reproduce: Below is complete code which I am working on:
**JS**

jQuery(function($) {
 var fbTemplate = document.getElementById('fb-editor');
 var options = {
 disabledActionButtons: ['data','clear','save']
 };
 var formBuilder = $(fbTemplate).formBuilder(options);
 document.getElementById('getJSON').addEventListener('click', function() {
 alert(formBuilder.actions.getData('json'));
 });
 var fbTemplate1 = document.getElementById('fb-editor1');
 var options1 = {
 disabledActionButtons: ['data','clear','save']
 };
 var formBuilder2 = $(fbTemplate1).formBuilder(options1);
 document.getElementById('getJSON1').addEventListener('click', function() {
 alert(formBuilder2.actions.getData('json'));
 });
});

**HTML**

 Get JSON Data

 Get JSON Data

Hi @kevinchappell,
Please help me with this as I am totally stuck with this issue.
Thanks!

Take a look at URL and use the result of the initialisation promise

I can see this in Section. But when I use promise and store the objects in an array, all the other objects get overridden by the last object.

coffee
 @formBuilder = []
 for element in $('#tab1, #tab2')
 dataElement = JSON.parse($(element).children('span').text())
 _initProgramBuilder(element, (dataElement || []))

 _initProgramBuilder = (element, data) ->
 $(element).formBuilder().promise.then (fb) ->
 @formBuilder.push fb

Same here @kirykr
Did you find a solution, i have two form builder, and calling "actions.getData()" only return last one..
I am already using promises...

Hello. Who was able to solve this problem? I ran into it and all methods do not help

You can only initialise a single formBuilder instance at a time and need to wait for the promise to resolve before moving onto initialising the next instance.

This can be done either via a recursive function per URL

or via awaiting the promise per the documentation.

The initial code by @Sharad2390 can be rewritten with the ready callback being async and the initialisation await the promise object of formBuilder

js
jQuery(async function($) {
 var fbTemplate = document.getElementById('fb-editor');
 var options = {
 disabledActionButtons: ['data','clear','save']
 };
 var formBuilder = await $(fbTemplate).formBuilder(options).promise;
 document.getElementById('getJSON').addEventListener('click', function() {
 alert(formBuilder.actions.getData('json'));
 });
 var fbTemplate1 = document.getElementById('fb-editor1');
 var options1 = {
 disabledActionButtons: ['data','clear','save']
 };
 var formBuilder2 = await $(fbTemplate1).formBuilder(options1).promise;
 document.getElementById('getJSON1').addEventListener('click', function() {
 alert(formBuilder2.actions.getData('json'));
 });
});

Hello. Thank you for giving a hint, which helped partially, but now I have encountered another problem in the form, the fields are displayed correctly, but when I want to get data from the form in json format, I have the same code on page 2 and 3. I've been struggling with this code for several days, I don't know what to do anymore.

I have 3 pages now:
1 - Text field
2 - Date field
3 - Header fields

These fields in the form will visually display correctly. There is no error with "actions.getData" now, but when I view the result var json = fb.actions.getData('json', true); then I get

1 - Text field
2 - Header fields
3 - Header fields

After the first it is duplicated

document.addEventListener('DOMContentLoaded', async function() {
 jQuery( function ($) {

 var fbOptions = {...};

 fbInstances.push($(".build-wrap").formBuilder(fbOptions));

 setTimeout(function() {
 $.each(setFormData, function(i, item) {

 if(fbInstances[i]) {
 fbInstances[i].actions.setData(item);
 } else {
 addPageLoading(item);
 }
 });
 }, 2000);

 // add pages form
 async function addPageLoading(data){
 console.log('addPageLoading')
 const tabCount = document.getElementById("tabs").children.length;
 const tabId = "page" + tabCount.toString();
 const newPageTemplate = document.getElementById("new-page");
 const newTabTemplate = document.getElementById("add-page-tab");
 const newPage = newPageTemplate.cloneNode(true);
 newPage.setAttribute("id", tabId);
 newPage.classList.add("build-wrap");
 const $newTab = newTabTemplate.cloneNode(true);
 $newTab.removeAttribute("id");
 const tabLink = $newTab.querySelector("a");
 tabLink.setAttribute("href", "#" + tabId);
 tabLink.innerText = "Page " + tabCount;
 $newTab.append($(" X ")[0])

 newPageTemplate.parentElement.insertBefore(newPage, newPageTemplate);
 newTabTemplate.parentElement.insertBefore($newTab, newTabTemplate);

 fbPages.tabs("refresh");
 fbPages.tabs("option", "active", tabCount - 1);

 if(data.length){
 fbOptions.formData = data;
 }else{
 fbOptions.formData = [];
 }

 var formBuilder_load = await $(newPage).formBuilder(fbOptions).promise;
 fbInstances.push(formBuilder_load);

 }

 // Get JSON and send form
 $(document.getElementById("getJSON")).click(function () {

 const allData = fbInstances.map((fb) => {
 var json = fb.actions.getData('json', true);
 return json;
 });
 $("input[name='json']").val("["+allData+"]");
 $("#design-form").submit();

 });

 });
});

Hi @Abacaxi-Nelson here is what I did

coffee
@formBuilder = []
startIndex = 0
 _initMultipleFormBuilder = (startIndex, elements) ->
 if startIndex
 form.element = elements[startIndex]
 @formBuilder.push form
 startIndex++
 _initMultipleFormBuilder(startIndex, elements)
 )

I use a recursive function. I haven't tracked it down why it works this way yet. Let me know if there is still a problem.

@Repechinskyi the first time you initialise formBuilder you don't use the promise

`fbInstances.push($(".build-wrap").formBuilder(fbOptions));`

and then further on you use do

javascript
var formBuilder_load = await $(newPage).formBuilder(fbOptions).promise;
fbInstances.push(formBuilder_load);

Fix up the first initialisation and it should work for you.

@kirykr The recursive method works well too.

Multiple forms on the same page
### Description:

Hi,

I try to have multiples forms on the same page (one for each language).
However, when I try to get data, it's always the data from the last form.

Thanks.

### Environment Details:

 - formBuilder Version: 3.4.2
 - Browser: Chrome 83
 - OS: MacOS

### Expected Behavior

Data of all forms

### Actual Behavior

I get data of last form instead of data of each form.

### Example

 URL

 Save

var formsBuilder = [];

$(function() {
 $('.form-editor').each(function() {
 var culture = $(this).attr('data-culture');
 formsBuilder[culture] = $(this).formBuilder();
 });

 $(document).on('click', '#save', function() {
 $('.render').html('');
 for (var culture in formsBuilder)
 {
 $('.render').append(culture + ' ');
 var data = formsBuilder[culture].formData;
 $('.render').append(data + ' ');
 }
 });
});

I have the same issue, however I am trying to render multiple forms on one page, and formRender.('userData') only retrieves the user data from the last form as well.

Only initiate multiple form builder instance with promise & recursive function. Check example here.

 URL

Sure, here is the sample of my usage.

### Initiate Multiple Instances

javascript
let formIDs = ['#form1', '#form2']
let fbInstances = []
let options = [............]

let init = function(i) {
 if (i {
 fbInstances.push(res)
 i++
 init(i)
 })
 }
}

init(0)

### Get Data from All Instances on Submit

javascript
const formData = []

fbInstances.forEach(fbInstance => {
 formData.push(fbInstance.actions.getData())
})

when I do this, I get `Cannot read property 'then' of undefined`. the first form id in `#form1` gets rendered, but the second one never does. any advice?


Question: waardelijst soortblusinstallaties, niet compleet?

Gesloten, omdat het verwerkt is in versie 1.2 en omdat die versie goedgekeurd is.

waardelijst soortblusinstallaties, niet compleet?
Onderstaand de huidige inhoud van de waardelijst soortblusinstallaties V1.0.
Daaronder de lijst zoals in BKL, bijlage VII tabel B.3.
Vraagt dat om een uitbreiding van de waarden in de IMEV lijst?

image

Informatie over blusinstallaties uit BKL VII tabel B.3

**Beschermingsniveau volgens PGS 15, blussysteem en stikstofgehalte**

**Beschermingsniveau 1**
(Semi-)automatische monitorinstallatie
Automatische deluge installatie
Automatische hi-ex outside-air installatie, stikstofgehalte 10%
Bedrijfsbrandweer met ter plaatse blussen, stikstofgehalte 10%

**Beschermingsniveau 2a, stikstofgehalte 10 %**
ADR-klasse 3 in kunststof
ADR-klasse 3 niet in kunststof
Geen ADR-klasse 3

**Beschermingsniveau 3**
Stikstofgehalte 10%

**Alle beschermingsniveaus**
 Gasflessen

reactie Manuel Betermans (RWS)
Ik ben het met jullie eens dat de lijst in de tabel van het Bkl en die uit het IMEV overeen zouden moeten komen; mij is niet bekend waarom hier een verschil in zou moeten zitten. Een tijd geleden hebben Hans de Waal en Wim Makaske (nu niet meer bij ministerie en bij ons werkzaam) een inventarisatie gemaakt van kenmerken die in de IMEV’s moesten. Op pagina 5 hebben ze dit voor tabel B3 gedaan, maar daar mis ik bijvoorbeeld in hun opsomming ook een Automatische hi-ex outside-air installatie; mij is niet duidelijk waarom dat zo is. Ik zou dus toch tabel B3 en de aanvullingen die Paul heeft gedaan als uitgangspunt nemen.
Wat uit dit document wel naar voren komt, is dat bijvoorbeeld een veld als ‘Oppervlakte opslagplaats in m2’ ook in het IMEV terug zou moeten komen. De uiteindelijk afstand uit tabel B3 hangt namelijk ook mede daarvan af; daarom is ook het beschermingsniveau als extra kenmerk voorgesteld (zie issue Opname Beschermingsniveau #18).

zie ook doc:

Werkgroep:
- wat is de argumentatie achter keuze van de huidige waarden in de waardelijst
- alleen die (11) opnemen waar niet te berekenen achterstaat (tabel B3, Bkl) blz 264, bijlage VII
- kom met voorstel

Klopt het dat het er 12 zijn en niet 11 zoals eerder in dit issue genoemd?

Werkgroep.

Bekijk dit opnieuw.
- Wat is de bedoeling van dit attribuut? Je wilt weten op welke waarde uit tabel B3 de afstand is gebaseerd.
- In feite is dat de eerste kolom van de tabel.
- In die tabel zit structuur. Dat is nu vertaald naar meerdere attributen
- voorstel: kijk of je een enumeratie kan maken waar die structuur in zit. Voorstel naam van de enumeratie. ..... Tabel B3.....

Voorstel voor enumeratie waar de inhoud van tabel b3 in is verwerkt.

image

Bericht Boudewijn:
Naar de mening van Rogier en mijzelf is het niet nodig of gewenst om - naast de nieuwe tabel - andere attributen te behouden. Stikstofgehalte, ADR in kunststof verpakking, etc. zijn alleen relevant bij bepaalde systemen en uit de nieuwe tabel blijkt duidelijk wanneer een specifiek aspect relevant is.
Dus alleen de enumeratie van de nieuwe tabel (BeschermingsniveauTabelB3) en daarnaast de 'oppervlakte' zijn relevant voor de aan te houden vaste 'afstand'.
De andere attributen (SoortBlusinstallatie, CategorieStikstofgehalte, OpslagADRklasse3, opslagGasflessen) kunnen dus worden verwijderd.

Opname Beschermingsniveau
Indiener: Manuel Beterams

Beantwoord door: Frank Zwiers

**Vraag:**
Klopt het dat er in het IMEV voor de opslag van verpakte gevaarlijke stoffen met vergunningplicht (en het gegevenswoordenboek) het beschermingsniveau van de opslag niet is opgenomen?

We hebben nog naar de tabel B.3 uit het Bkl bijlage VII gekeken en in lijn met wat Wim Makaske en Hans de Waal ook hadden geconstateerd, lijkt het ons belangrijk om het beschermingsniveau toch op te nemen in het informatiemodel.

**Antwoord:**
De keuze om dit niet oorspronkelijk niet op te nemen is wel wat te verklaren denk ik. Bij dit kenmerk is in de BKL geen enkele afstand genoemd. Dit kan je dan zien als ‘kopjes’ in de tabel.
Alle kenmerken waar een een afstand wordt bepaald staan er wel in en dat was de reden dat de lijst is opgesteld.
Rinus de Bruijne heeft het beschermingsniveau kenmerk volgens mij ook al eens benoemd in 1 van zijn mails.
Tot zover de analyse, lijkt me dat als dit een nuttig kenmerk is dit op de changelist moet zodat het toegevoegd kan worden.

Bij welk object hoort dit attribuut potentieel? Bij IMEV:OpslagVerpakt_TeBerekenenAfstandVergunningsplicht

is dit wat er wordt bedoeld? Alle classificatie informatie is nu in het objecttype vastgelegd, inclusief het beschermingsniveau:
image

Beste Paul, hierbij zoals verzocht de reactie van Geodan:

Technische impact: De REV API specificatie moet gewijzigd worden.

Bovenstaande laatste opmerking beschrijft het wijzigingsverzoek.
Deze 2 objecttypen komen voor als subtype van BLKActiviteit:
<img width="420" alt="image" src=" URL

- alle beschermingsniveaus kan weg.
- alleen opnemen bij te berekenen afstanden. optioneel
- Beschermingsniveau 1: Beschermingsniveau 1 volgens PGS 15


Question: Scala 3 generated @main function is generated in package scope?

@EugeneFlesselle @jan-pieter @nmcb we will use the following Zoom link for today:
 URL

Scala 3 generated @main function is generated in package scope
## Compiler version

Scala 3

## Minimized code

Suppose you are converting a Scala 2 application that has 2 main methods in the same package. This is not that uncommon as you may put applications in a `app` package. Here is the code, put in the same file for simplicity for the issue.

scala
package app

object Foo {
 def main(args: Array[String]): Unit = println("Foo")
}

object Bar {
 def main(args: Array[String]): Unit = println("Bar")
}

Now you are converting this Scala 3 or just happen to want to add another application and you like the name `main` for your entry point as you are used to that convention. You convert the `args` using the documentation as you would get an conversion error **No given instance ...** if you left it as an `Array[String]`.

scala
package app

object Foo {
 @main def main(args: String*): Unit = println("Foo")
}

object Bar {
 @main def main(args: String*): Unit = println("Bar")
}

## Output

Now this second example doesn't compile with a **main is already defined as main ...** error pointing to one or the other application that was compiled first.

## Expectation

Generated or synthetic code should be scoped to the scope it is found in. It seems weird that code found in `object` scope is generated in package scope. This may be a more advanced way of thinking about this. The overall point is this is really surprising and bound to catch people because of the overall ergonomics.

There is also an additional surprise as follows:

scala
package baz

object Bar {
 @main def main(): Unit = println("main Bar")
 @main def bar(): Unit = println("bar Bar")
}

Results in a warning (maybe for case insensitive file systems or something).

scala
warn] 9 |object Bar {
[warn] | ^
[warn] |Not generating the static forwarders of Top(baz.Bar) because its name differs only in case from the name of another class or trait in this compilation unit.

Note that main functions are not really special in Java except for the signature. They can be called by other code like a normal function.

I know the intent was to try and make entry points easier, nicer, and more flexible with less boiler plate. These sort of "edge" cases or just stuff people may try to do will be very unexpected.

Thanks.

I wouldn't say this is a bug - it was documented to behave this way: URL

Yes, I agree. Feel free to categorize it appropriately.

Overall to me, it seems to just sort of defy the normal idea of scope. Top level scope is a different thing. Like I said above, I don't think it is that unusual to have more than one app in the same package.

I like the typed arguments but I'm wondering if this will cause others troubles too, when the whole idea was to make things easier with less boilerplate.

I'm not sure if we want to change this behaviour, effectively breaking backwards compatibility... And I'm not even convinced if having multiple functions annotated as `@main` in a single codebase is even a good idea. But I see what you mean, there definitely would be a usecase.

As a middleground what I'm thinking is, maybe it'd be sufficient to improve the warnings to make this predictable?
What I mean is, for this example:

scala
package baz

object Bar {
 @main def main(): Unit = println("main Bar")
 @main def bar(): Unit = println("bar Bar")
}

We currently (3.6.0-RC1-bin-20240807-54344a1-NIGHTLY) warn like this:

scala
[warn] ./repro.scala:3:8
[warn] Generated class baz.Bar differs only in case from baz.bar.
[warn] Such classes will overwrite one another on case-insensitive filesystems.
[warn] object Bar {
[warn] ^

The warning about generated classes doesn't explain the core issue to the user, maybe we could warn specifically for the duplicated `@main` here?

My students have made all sorts of unaniticipated usages of @main-funcs over the last semesters with Scala 3 -- I try to solve this by saying that the should not name their @main `main` and have unique name. **A good warning with good hints of how to solve the issue would be nice.** (We use top-level @main almost always now, but the story on the legacy with actual main with string array in relation to what the JVM requires needs to be told eventually when they have gotten a bit further, so that students now how to interpret what a main actually is and how to get out of strange edge cases like this...)

Realistically, you can't have 2 mains (functions with the same signature) at any scope level so if `@main` is at the top level, it makes sense that you can't have 2 `main`s. At a different level, like scope inside an `object` we could always have a `main` per object. Now that we are having the annotation for main, we should just allow that to continue. In the end, generating a main or not, the semantics of what is written as a function, should really just act like a function. How the code is generated should not really alter the concept of the code that is written.

In this case it is just a warning but otherwise I can run this in VSCode and Metals.

scala
package baz

object Bar {
 @main def main(): Unit = println("main Bar")
 @main def bar(): Unit = println("bar Bar")
}

What concerns me about this is I have written `baz.Bar.bar` and `baz.Bar.main` so without the annotation this seems like normal code. How that works I have no idea - I haven't looked at the generated byte code. If that isn't allowed I understand but it works - not sure why the `bar` function is lifted so the compiler sees the `object baz.Bar` and then the function `baz.Bar.bar` becomes `baz.bar` so then there is a warning. A child or beginner is unlikely to understand the file system case insensitive issue.

The following example works perfectly fine. Maybe I wasn't clear. My objection was that I couldn't have 2 `main` with the same signature inside different `object`s in the same package - I can rewrite those as a normal `main`s and have as many as I want but then I can't take advantage of the `@main` functionality.

scala
object Foo {
 @main def main(args: String*): Unit = println("Foo")
}

Perhaps I should have put my first example that works - but with the warning. I even get like `run` lenses so I can run them all.

scala
package baz

package foo {
 object Foo {
 @main def main(): Unit = println("Foo")
 }
}

object Bar {
 @main def main(): Unit = println("main Bar")
 @main def bar(): Unit = println("bar Bar")
}

The 2 `main`s are ok because they are in different packages. That was a modification from my original try with 2 `object`s with `main`s in the same package that didn't convert directly across from actual code in the wild.

I am unclear on the compatibility issue of the generated mains unless it is tool or TASTY related.

I imagine this could be a problem since naming is difficult and a lot of people will just do `@main def main =...` everywhere :sweat_smile:

Would it be possible to automatically resolve such conflicts? I see two options:
- if we have the same named methods with `@main` annotation then add some synthetic number to the name?
- or if leave the second method inside it's current scope, generate the object inside the current object where the method is defined

This should be largely compatible, since currently this is an error, but I am not sure if it's doable?

Adding trailing numbers 1.. to disambiguate sounds like a simple and useful enhancement. (Similar to scala-cli and the sbt shell when you run and there are multiple mains)

I extracted the warning for 2 `@main` annotations for differently named methods in a single object to #21365, as that seems like a separate, reporting issue.

The requirements for this is to:
- try to support `@main` annotation for multiple methods under the same name
- not break backwards compatibility

Methods to achieve this have been discussed above, we're not sure what (and if anything) would turn out feasible. It may turn out we end up not supporting this, but it may be worth a try.

Just to re-clarify, as noted in #21365, having multiple `@main` methods with different names _is_ already supported:

scala
// ~/scala-snippets-6/multi_main.scala
object Bar {
 @main def main1(): Unit = println("main 1")
 @main def main2(): Unit = println("main 2")
}

➜ ~/scala-snippets-6 scala multi_main.scala --main-class main1
Compiling project (Scala 3.5.0, JVM (17))
Compiled project (Scala 3.5.0, JVM (17))
main 1
➜ ~/scala-snippets-6 scala multi_main.scala --main-class main2
Compiling project (Scala 3.5.0, JVM (17))
Compiled project (Scala 3.5.0, JVM (17))
main 2
➜ ~/scala-snippets-6 scala --version
Scala code runner version: 1.4.0
Scala version (default): 3.5.0

However, as each `@main` method results in a class with the method's name, this name must be different than other objects or classes. This is not the case for `object Bar` and `@main def bar` in the example above: ignoring case, these are the same.

What does _not_ work is other have two `@main` methods with the same name:

scala
object Foo {
 @main def main(): Unit = println("main 1")
}

object Bar {
 @main def main(): Unit = println("main 2")
 // error: main is already defined as class main

This is expected and spec'd that way: `class main` thus is already defined by the first `@main` so cannot be redefined.

To circumvent this issue, we would need to follow one of @tgodzik suggestions:

However:

- Synthetic numbers seem confusing to me: if there are several main methods, the user will ultimately need to specify which one to run using `--main-class`, so it better not be a generated name.
- Conditionally leaving the method in an inner scope seems hard to specify. Would that be done only if the method name would result in a clash in an outer scope?

All in all, it seems to me that the current behavior is probably okay.

Whatever we decide, it needs to be spec'd before someone can tackle this issue during an issue spree.

I guess this is pretty disappointing as methods with the same name and signature in 2 differently named `object`s in the same package are always allowed including standard `main` methods like `def main(args: Array[String]): Unit = ???`. Adding the `@main` to these and changing the signature to `String*` doesn't work. This doesn't pass the least surprise test and the user walks away wondering what synthetic code is generated.

I think that at least a good errormessage or warning should be given when problems arise. @mbovel Perhaps re-open this issue and rename it to something related to "improved error messages and warnings" ? There could be help included in the message how to cover the use cases outlined by @ekrich

How would you improve the error message? It currently says:

// error: main is already defined as class main

Would you special case it for `@main` methods?

// error: main is already defined as @main method main

I guess we could re-purpose this issue, or open a new one.

Unexpected warning when `@main` is used twice within a single object
## Compiler version
3.4.2, 3.3.3, 3.6.0-RC1-bin-20240810-ba2c731-NIGHTLY

## Minimized code

scala
package baz

object Bar {
 @main def main(): Unit = println("main Bar")
 @main def bar(): Unit = println("bar Bar")
}

## Output

scala
[warn] ./repro.scala:3:8
[warn] object Bar differs only in case from class bar in package baz. Such classes will overwrite one another on case-insensitive filesystems.
[warn] object Bar {
[warn] ^

## Expectation
One of two:
- a better warning about using the `@main` annotation twice, if needed
- no warning, as this particular code is valid and both main methods (`baz.bar` & `baz.main`) can be accessed.

bash
scala-cli run repro.scala --main-class-ls
# [warn] ./repro.scala:3:8
# [warn] Generated class baz.Bar differs only in case from baz.bar.
# [warn] Such classes will overwrite one another on case-insensitive filesystems.
# [warn] object Bar {
# [warn] ^
# baz.bar baz.main

## Context
Extracted out of:
- URL

This issue was picked for the Scala Issue Spree of tomorrow, August 13th. @EugeneFlesselle @bracevac @jan-pieter and @nmcb will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

The issue has nothing to do with multiple `@main` annotations. As the warning correctly points out, the naming will cause issues with non-casesensitive filenames. So there is nothing to be done here.


Question: Adding UNITASK_DOTWEEN_SUPPORT scripting define results in a ton of warnings about not awaiting a tween/sequence?

Ah yeah. I don't think that's too bad.

However, isn't it a bit confusing that the presence or absence of `using UniTask` changes whether or not a discard is required?

Adding UNITASK_DOTWEEN_SUPPORT scripting define results in a ton of warnings about not awaiting a tween/sequence
I'm using DOTween for tweens and UniTask for async. I didn't realize for a while that DOTween was supported directly but a script define had to be added. So I went to add it today and it results in a ton of warnings on my tweens/sequences saying "Because this call is not awaited, execution of the current method continues before the call is completed. Consider applying the 'await' operator to the result of the call.". Some examples of code:

Sequence s = DOTween.Sequence();
// every line after this shows the warning
s.Append(container.DOFade(1, 0.75f));
s.AppendInterval(this.mediaDuration);
s.Append(container.DOFade(0, 0.75f));
s.SetId(this.GetInstanceID());

Tween t = container.DOFade(0, 0.25f);
bool wasKilled = false;
// the following line shows the warning
t.OnKill(() => wasKilled = true);

// all regular tweens show it too
this.rightQuestion.DOFade(1, 1);

Any way to make these warnings go away? I think the issue is that Tweens are directly awaitable (`await this.rightQuestion.DOFade(1, 1)`). I wonder if it would make more sense to require calling a function on the tween/sequence in order to await the tween. For example, without the script define, you have to do `this.rightQuestion.DOFade(1, 1).AsyncWaitForCompletion()` in order to await the tween. For UnityWebRequests, you have to call `SendWebRequest` in order to await it. Seems like it would be more consistent with other objects if you had to call a function and it would remove all the warnings.

I was just thinking about the same problem.
For safety reasons, I would like to treat CS4014 as an error, but it is difficult to correct all the parts that use DOTween.
Is it possible to provide a define symbol for disable the `GetAwaiter` extension method?

Duplicate of #452 .

Unfortunately it seems difficult to support anything officially.
There is an option to use `#pragma warning disable CS4014` . And if you want to convert to UniTask you can use `.Forget()`.

Yeah, not impossible, but breaking changes with significant impact.
Apparently, when this library was created, the compiler did not warn about the extension methods. So at the time, the API seemed reasonable. However, making a major change to this is a big deal.

I wonder if this is a method provided by DOTWeen. This uses System.Threading.Task; UniTask provides a more optimized implementation than Task.

`SendWebRequest()` has exactly the same problem as this issue. It returns Unity's AsyncOperation, which Unity is not designed to await, but UniTask provides an extension that allows it to await.
If an object representing an asynchronous operation has been created and is running, being able to await it as is is certainly easier to use. I think the problem is that tween is used in a way that does not wait for completion. Your suggestion is one way to do it, but I think it has a lot of impact and is something to consider.

Hmm, yeah that makes sense. I wonder how many people use this package with DOTween enabled? I didn't even realize it could be enabled and I've been using this for awhile. Sometimes breaking changes for the betterment of the package is necessary... sometimes I wish Unity would just break some things to make their APIs better, like the fact that actions (like OnClick) don't return the sender as the first parameter (which is what Microsoft recommends for events). But I could see an argument for not breaking it... but honestly my preference would be to break it with a major version update.

Yes, this is a function that DOTween provides that can be directed awaited. I usually call `AsUniTask()` on it, not really sure if that's needed it makes it more optimized or not, so it looks something like `await aCanvasGroup.DOFade(1, 0.75f).AsyncWaitForCompletion().AsUniTask();`. Right now, since I don't have the DOTween part enabled, if I want to add a cancellation token to it, I then chain `.AttachExternalCancellation(token);` to it, and in the `catch` part I kill the tween manually (since the cancellation doesn't cancel it itself, I'm assuming because it's an "external" cancellation). If I enable DOTween support, I can do just the regular `WithCancellation(token)` (I think) and it will kill the tween without me having to do it.

Hmmm, I think Unity's AsyncOperations are allowed to be awaited. I've done `await www.SendWebRequest()` even without UniTask installed and it works as expected. With UniTask installed, I don't know if it's better to leave it like that or do `.ToUnitTask()` on it and await that. If I need to add a cancellation token to it, I do `await await www.SendWebRequest().WithCancellation(token);`

But in general, I would still support just breaking it and letting people know it's going to change/break. As an alternative, I wonder if a fork could be created that has these breaking changes in it? I don't know if there's another solution. Maybe a different scripting define? So you have two versions of the DOTween extensions, one that is the original and one that changes the way it works and then the scripting define can be like UNITASK_DOTWEEN_SUPPORT_ALT or something. So people can choose to stick with what they are using or use the new one.

DOTween CS4014
I get an error `warning CS4014: Because this call is not awaited,
execution of the current method continues before the call is completed.
Consider applying the 'await' operator to the result of the call.`

In the following code:

csharp
private async UniTask DoMagic()
{
 // await logic here
 ...
 // DOTween
 var seq = DOTween.Sequence();
 for (int i = 0; i < n; ++i) {
 seq.Insert(time, transform.DOScale(0.3f, 0.1f); // CS4014
 .Insert(time, transform.DOMove(Vector3.zero, 0.1f);
 }
}

How to suppress it?

Use something like:

#pragma warning disable CS4014 // disable warning

private async UniTask DoMagic()
{
 // await logic here
 ...
 // DOTween
 var seq = DOTween.Sequence();
 for (int i = 0; i < n; ++i) {
 seq.Insert(time, transform.DOScale(0.3f, 0.1f); // CS4014
 .Insert(time, transform.DOMove(Vector3.zero, 0.1f);
 }
}

#pragma warning restore CS4014 // restore warning

You could also just use a single pragma at the top of the file.

@desmondfernando thanks for reply! But it's not the best solution to write pragma everywhere :(

Thanks for the trick! A permanent solution would even better :)

Hmm.. there seems to be no better way than `#pragma ` .

Note:
C# does not make extension methods a warning until after UniTask was released.
If extension method is in a different namespace, it may be possible to control the use of extension method only when you want to wait, but it is difficult to change it now.

@hadashiA What about using discards? URL

This line gives me the compiler warning about not awaiting a tween:
`myGameObject.transform.DOLocalMoveY(1, .5f).SetEase(Ease.InBack);`

But the compiler warning goes away when I use a discard, like this:
`_ = myGameObject.transform.DOLocalMoveY(1, .5f).SetEase(Ease.InBack);`

I agree that it's confusing, and seems to leave the compiler as a guide to where to use the discards because it's not readily apparent where and why they are used. Maybe at best it's a preferable alternative to `#pragma warning disable CS4014` and at worst, it's confusing without a comment in the code to explain the purpose?

If this happens because of UniTask, another way to handle this is to convert it `ToUniTask`, and then `Forget` it , like `myGameObject.transform.DOLocalMoveY(1, .5f).SetEase(Ease.InBack).ToUniTask().Forget();`


Question: Carthage Xcode >=12 compatibility?

@mman I've been bashing my head against against something for a minute now... I've got my branch rebased with mainline, but it seems like no matter what I do, I can't get the tests to see the main source files. You're doing it with cSettings I gather, but when I do similar, they seem to be ignored.

Do you know of any reason why this might be? The only differences I can see are that I use the path and publicHeadersPath attributes.

Carthage Xcode >=12 compatibility
Generate xcframework for the next version in order to avoid using carthage workaround

 URL

@cbaker6

We may be moving straight to SPM support and skip fixing the carthage build altogether, see discussion in URL In the meantime, I found a rather complex way to build with carthage on Xcode 13.2.1:

1. Use carthage build script `carthage.sh` for Xcode >12 compatibility
2. Build all xcframeworks; do not use `--no-use-binaries` as `facebook-ios-sdk` is required as dependency of Parse SDK but cannot be built from source in Xcode 13; run: `./carthage.sh update --use-xcframeworks --platform iOS`
3. Add built xcframeworks to Xcode project, except `Parse.xcframework`
4. Open `Carthage/Checkouts/facebook-ios-sdk/samples/SmoketestSPM/SmoketestSPM.xcodeproj` and wait for SMP to download the dependency; see here.
5. Build Parse SDK frameworks because `ParseFacebookUtilsV4.xcframework` requires `Parse.framework` (not as xcframework), so it needs to be built and added via `carthage copy-frameworks` in the Xcode project's build phases; run: `./carthage.sh update Parse-SDK-iOS-OSX --platform iOS`

I'm keeping this issue open as a thread to look for help when building with carthage, but with a note that we intend to focus on Swift Package Manager support ( URL instead of fixing carthage build process.

Closing as release 2.0.0 supports import via Swift Package Manager.

Support Swift Package Manager
Parse has two dependencies, **Bolts** and **OCMock**.

I think Bolts is not maintainability, so If we want to keep the Parse-Objc or support latest tech stacks like SPM, I think fork the Bolts is a better option.

Here is my suggestion.

1. Fork Bolts and OCMock into the parse-community.
2. Make a Package.swift for Bolts and OCMock to support SPM.
3. Make a Package.swift for Parse-SDK-iOS-OSX.

That's it.

What do you think about this?

Another option is to focus on the **Parse-Swift** like Parse Dart SDK.

PS. FireBase also has dependencies with OCMock. URL

Would we actually need to do anything to OCMock? It's not part of the distribution as far as I can tell; it's a development dependency.

FYI I don't know anything about SPM yet, but I assume it would be used to install the client to projects. Just using the SDK in a project doesn't require OCMock.

This sounds like a great idea. Do you want to open a PR for the iOS part of the process?

@mrmrcsmith I can’t fork into the area repository. Could you fork it? I’ll make a PR

sure! It would be great if your PR included some instructions in the README on how to use SPM with Parse since this would be my first experience using SPM so I'm sure lots of other people are curious how to use it too.

Anyone should be able to fork parse. Thats super weird.

So, I'm curious if we could talk to the bolts guys about just turning the repo to us. Like Parse, Bolts was previously maintained by Facebook and at around the same time as Parse they turned over Bolts to community contributors. So, theres probably at least a little report with them. Not to mention Parse is probably the largest application to use Bolts.

SPM is getting more popular recently and with WWDC and Xcode updates coming soon I'm guessing it will only increase.

Just bringing this up to see if we can re-open and figure out what to do with Bolts.

@noobs2ninjas has been communicating with FB open source so if someone wants to make a PR to bolts to support SPM we could probably get it merged now.

Just to clarify, the PR is needed to Bolts-ObjC as the Swift version of Bolts is already SPM compatible.

Definitely bumping for support especially since now SwiftPM has a gui and has been updated to handle frameworks better. Its far easier and less cumbersome then pods at this point.

We would gladly accept a PR for this, as I understand we still need SPM support from Bolts-obj.

Right now I'm working on a fork of our dependency Bolts-Objc with SPM support. Once that works, I'll see if I can do the same to the SDK.

I can't give you an estimate on completion, sorry.

I've got a PR open against Bolts that adds SPM support.

Started looking at this library today.

For real though, if they announce that Objective-C imports will soon just work with SPM at WWDC this week... I'm gonna scream so loud.

Maybe not an option for everyone but there is a rebuild of the Parse API for iOS in Swift: URL

There's nothing newer than what's on my branch right now that I'm aware of. But the main Parse SDK imports properly using SPM in that branch IIRC.

I do plan on getting it working, but I need to find time.

I'd welcome any help. PR is here.

Problem is, its currently missing a lot of features and because they renamed a bunch of methods new users may struggle to implement it until documentation is updated accordingly.

It's not difficult to implement. And what features are you missing?

A quick example would be say you have a new user starting with back4app and in the tutorial to confirm you set it up right they have this code:

var person = PFObject(className:"Person")
person["name"] = "John Snow"
person["age"] = 27
person.saveInBackground {
 (success: Bool, error: Error?) in
 if (success) {
 // The object has been saved.
 } else {
 // There was a problem, check error.description
 }
}

//Reading your First Data Object from Back4App
var query = PFQuery(className:"Person")
query.getObjectInBackgroundWithId("mhPFDlCahj") {
 (person: PFObject?, error: NSError?) -> Void in
 if error == nil && person != nil {
 print(person)
 } else {
 print(error)
 }
}

This will fail because IIRC Parse-Swift doesn't use PFObject. I am not saying ParseSwift is difficult to implement, in fact its easier given SPM. However renaming methods etc make it more difficult to follow older parse tutorials. I could be completely wrong here, I have limited parse experience personally.

Yes, that's correct, but it's more Back4App that needs to update their docs for ParseSwift also. I came from Parse for objective c, and then switched to ParseSwift.

There is a playground example in ParseSwift that show you how to use it. It's actually really easy. The documentation for ParseSwift is also well written.

I personally strongly advice to switch to ParseSwift. But that's my opinion.

That's not a bad idea ill give the playground a shot because I hate dealing with CocoaPods etc. I appreciate the offer and will give it a shot.

I have started prototyping swift package manager support for Bolts and Parse-SDK-iOS-OSX in a similar way as @drdaz.

_[For new projects it may be the obvious choice to use URL but for existing projects migrating to a new client side SDK may pose more troubles then integrating subset of old Objective-C SDK via swift package manager.]_

To simplify things I removed all Carthage, Cocoapods, rake, and Xcode related scripts and files and only left the headers, sources, and added super simple Package.swift.

My version of Bolts is here: URL

You can `swift build` and `swift test` it, I temporarily removed all the app link and webkit stuff. If you compare it against the parse-community forked main branch of Bolts-ObjC, you will see that I basically only fixed all includes to be fully qualified.

My version of Parse-SDK-iOS-OSX is here: URL

You can `swift build` it for all platforms. Tests are not yet incorporated. Build is not clean and produces warnings, mainly because it always tries to compiles all files for all platforms, and many files are platform specific and should be excluded.

FacebookUtils, TwitterUtils, and ParseUI are ignored and not supported for now.

Looking at tree comparison, I again only left sources, headers, and added simple Package.swift file, fixing all public API includes to be fully qualified.

I will continue using these branches in my own projects and keep them up to date over time. If you are interested I can open a PR against master and try to continue working on getting this integrated, but first we probably need to agree on scope and goals for the effort. Parse-SDK-iOS-OSX is rather complex and contains lot of things that I believe should be split out as separate packages that depend on Parse.

FacebookUtils, TwitterUtils, and ParseUI are obvious choices.

My personal goal is to make `swift build` and `swift test` pass cleanly on all supported platforms, that is iOS, macOS, tvOS, watchOS, macCatalyst.

Just my .2 euro cents, opinions?

Due to the accumulating difficulties regarding carthage and xcframework building on Xcode >=12 I've added a bounty to SPM support in the hopes to incentivize and revive this effort. I've also marked the issue Carthage Xcode >=12 compatibility as bug that won't be fixed, so we can fully focus on SPM support.

I have been able to re-introduce Parse SDK test files into URL and make them compile for macOS, and iOS. tvOS, and watchOS need to be done.

Quick run of `swift test` makes majority of the tests pass, with couple failing for various "assumption" reasons that were valid in the Xcode days (always present Info.plist, always having hosting UIApplication, etc).

Will continue working on them

@EliteTechnicalCare can you either “correct” or “delete” your comments about the Swift SDK? Neither were true when you posted them. This particular issue is currently pinned and will get more attention. I don’t want people coming across your comments perceiving them as facts when they are not. This is synonymous to when people tweet or post saying, “parse server is dead,” and others believe it.

What is true is what @mman posted:

@cbaker6 Have you come across any plans / demands for adding SPM support to the Parse Swift SDK? I think once we support SPM, we could also end support for all other dependency managers such as cocoapods and carthage? The 2 repos (ObjC, Swift) don't have to be aligned, but it would be interesting to know.

The Swift SDK has always supported SPM along with Cocoapods and Carthage. More info in the readme: URL SPM has always been labeled as the preferred way for the Swift SDK.

Amazing, I haven't noticed that. Maybe @drdaz could get in touch in case there are any obstacles in URL

They are just there for people who don't want to use SPM and are more comfortable the others. For the Swift SDK, it's not hard to keep support for Cocoapods and Carthage. SPM is definitely the easiest to use.

This is kind of a big deal. It means I won't have to dig into the challenges I was describing here. Running the tests using swift test make an awful lot more sense than what I was talking about 👍🏼

These things used to be separate GitHub projects not too many years ago, and I think they got reincluded in the main package because the other thing was a PITA - multiple CI's, dependencies to be maintained etc. Also, nobody is going to be interested in those packages that aren't using the main Parse SDK. Can you explain what benefits you see in splitting them out?

Both of these depend on 3rd party SDKs that may get broken at various stages of life blocking the updates and release of core Parse iOS SDK. It also makes the resulting binary bigger, it also then links your project to SDKs that you do not use and perhaps do not want to have linked at all (for example if I am not mistaken, just linking a facebook SDK to your app did in the past trigger various red flags during review, like linking against location, ads frameworks, etc., and IIRC facebook SDK used to track app usage and correlate with other apps usage just by being included in the app). /me do not like that.

Just my .2 cents, I like things to be lean and focused (my UNIX roots :)

SPM allows to select only the needed subpackages. Would that allow to add only the main Parse SDK without Facebook Utils and without the FB SDK as 3rd party dependency?

As @mman says, yes it should. I believe the only install route that suffers from everything always being installed is Carthage.

It's a legitimate concern, but since we specify which version of the FBSDK we use, the breakage generally won't catch us unawares. Moving between FB dep versions is an explicit, conscious action, and the developer should be able to see if the update breaks anything.

The only place I see this causing issues is when an Apple SDK update breaks whatever version of the FB SDK we're using. And if that happens, it's likely to be because we're hanging on an old version; FB seems to keep up to speed with Apple's newest stuff pretty well. Even then, the move to a newer Apple SDK is a conscious move.

@drdaz Do you have any error messages?

The line: URL here shows that tests must depend on Parse, Bolts, and OCMock, and we only use .headersSearchPath to actually lookup internal header files that are not public

hello everyone. is there any kind of update on this?
I currently have a `Package Resolution Failed` error
image

@danipralea What URL you specified as a dependency? I guess the way to the future is to use Parse Swift SDK implementation and fall back to this legacy repository only when you really need it and know what you are doing.

Feel free to use the `spm` branch of my fork from URL that should resolve and work just fine but the question is whether this will ever get merged at all? CC @drdaz ?

Got it. I think as long s this repo is embeddable with in some way, I think we're good. We made carthage work recently, so it's available I'd say.

Has there been any progress in adding SPM support? Is this something anyone would be interested to pick up?

@mman Could you open a PR from your `spm` branch, so others can see the diffs you had to do to get it work and build upon it?

Thanks, if you find some time, could you resolve the conflicts, so that these show the latest state compared to the target branches?

Hi everyone, @ricky641b will give it a shot to add full SPM support.

Luckily he can build on the PRs and investigations already done by you.

Let's support him with whatever questions he may have, to get this over the finish line - thanks especially to @mman, @drdaz!

Notes:

- cocoapods and carthage support can (or even should) be dropped when implementing SPM support. We are implementing SPM support because they actually don't work anymore in some scenarios. SPM solves this. Removing carthage & cocoapods should also make it easier for you to implement SPM, because it reduces the code base.

- The ParseFacebookUtils are required. The SPM implementation must make it optional to install it though, since not everyone may need it. Same with ParseTwitterUtils.

Could someone try out URL to add the SDK via Swift Package Manager?

cc @drdaz @mman

I can try it once again if you allow me to

On Thu, 5 Jan 2023 at 5:22 AM, Manuel ***@***.***> wrote:

--
Warm Regards
*Bhavesh Gupta*
Owner @ Atikin Technologies
 URL

@ricky641b The SPM integration should be done with this PR; with try out I meant to try to add the Parse Apple SDK via SPM in Xcode using this branch.


Question: Support Root-Relative Links (Absolute Links)?

I recommend adding an option to `urlConfig`, similar to `lines: boolean`, which is then checked for here. Something along the lines of: `resolveAbsolutePathsInRepo: boolean`? That way, folks can configure whether their hosted git supports this or not.

Furthermore, you are now creating a *path* inside `value`, in your `if` branch.
But the value we are making is a (serialized) *URL*.
`path.resolve` and `config.root` are all about paths. (note: see my last paragraph of this comment later touches on this again)

For reference, I checked the following in a private repo (`wooorm/private`) on GitHub:

`readme.md`

markdown
alpha
bravo
charlie
delta
echo
foxtrot

`x/y/z.md` (empty)

markdown

Github generates the following HTML for the readme:

html
 alpha
 bravo
 charlie
 delta
 echo
 foxtrot

That is to say, all absolute paths are prefixed with `/wooorm/private/blob/main`.
so `!config.urlConfig.prefix.startsWith(value)` and the current handling are not needed.
The information needed to construct `/wooorm/private/blob/main`, other than the branch,
is in `urlConfig.prefix`.
Missing a branch is fine, we don’t use it yet: URL

So, I personally would do something like the following pseudocode:

js
 // Absolute paths: `/path/to/file.md`.
 if (value.charAt(0) === slash) {
 if (!config.urlConfig.hostname) {
 return
 }

 // Create a URL.
 const pathname = config.urlConfig.resolveAbsolutePathsInRepo && config.urlConfig.prefix
 ? config.urlConfig.prefix + 'unknown' + value
 : value.slice(1)
 value = https + slashes + config.urlConfig.hostname + pathname
 }

…where `unknown` is a temporary value for a branch name, which is dropped later!

Finally, the function as I look at it now is a bit of a mix between path and URL handling.
That’s ambiguous and probably points to some bugs.
It’s probably better to investigate all that and look at it some more some other time though!

Support Root-Relative Links (Absolute Links)?
Hi @wooorm ! 👋

### Subject of the feature

What do you think about supporting root-relative links such as in the example below?

md
abc
abc

I suppose this could be configured with a configuration option, maybe named like `basedir`.

### Problem

On large sites with a lot of moving files or large directory structures, updating relative links can be a pain.

Root relative links can also avoid any ambiguity that can be caused by using the same path ending and file name between multiple files.

### Expected behaviour

It would be nice for these links to also be checked.

### Alternatives

gatsby-remark-check-links, but:

1. It's Gatsby-specific
2. It runs as a Gatsby plugin and only warns in the console :(

gh-action-check-broken-links, but:

1. It's wrapped in a GitHub Action
2. It assumes everything is in a `pages` directory

So in case `urlConfig` or some other configuration setting would be changed in `remark-validate-links` (unlikely, given that this project is GitHub / GitLab / Bitbucket focused), maybe it could work like this:

Config:

js
baseDir: '/src/pages',
extension: 'mdx',

`src/pages/lib-1/index.mdx`

mdx
To read more, check out the docs about `lib-2`!

The link above would be resolved to the file ` /src/pages/lib-2/docs.mdx`

Having this feature would be extremely useful, especially in monorepos where some markdowns reference other projects. Any news on this? 👀

Absolute paths are now supported like GitHub again, per URL
For arbitrary websites, so not markdown files on GitHub/Gitlab/Bitbucket, use `remark-lint-no-dead-urls`

Does not catch bad links that use absolute paths to repo root
### Initial checklist

- [X] I read the support docs
- [X] I read the contributing guide
- [X] I agree to follow the code of conduct
- [X] I searched issues and couldn’t find anything (or linked relevant results below)

### Affected packages and versions

12.1.0

### Link to runnable example

_No response_

### Steps to reproduce

I have a repo: URL If you run `./remark-check.sh` it will catch one bad link but not another bad link.

$ cat README.md
link

This should fail
link

But only this one actually fails
link

### Expected behavior

GitHub allows you to use absolute paths starting with `/` to mean the root directory of the repo. remark-validate-links should handle looking at the repo root to resolve these files.

### Actual behavior

Root-absolute paths are not validated.

### Runtime

_No response_

### Package manager

_No response_

### OS

_No response_

### Build and bundle tools

_No response_

This looks like URL but I think #57 is talking about the ability to rewrite certain root paths.

I'm not talking about that. I just want to be able to resolve files relative to the root of the same repo. No rewrites.

Hey!

I don’t think this was supported before.
But your repo shows that it does work.
I was under the impressions that they used to be related to `github.com`, like normal.

See this handling: URL

A PR to solve it would likely around that line.

And it might need some more testing, to see if `/wooorm/markdown-rs/...` still points to some other repo on GH, or to a file in the current repo.
And perhaps some testing on Gitlab / Bitbucket?

Interested in working on this?

I've got it working with this diff, but you're right there are some edge cases. I don't really care to test on gitlab/bitbucket since I'm not as familiar with them. So how do you feel about this?

git diff
diff --git a/lib/find/find-references.js b/lib/find/find-references.js
index 953dec3..f930f4d 100644
--- a/lib/find/find-references.js
+++ b/lib/find/find-references.js
@@ -217,14 +217,21 @@ export async function findReferences(ctx) {
 */
 // eslint-disable-next-line complexity
 function urlToPath(value, config, type) {
- // Absolute paths: `/wooorm/test/blob/main/directory/example.md`.
+ // Absolute paths: `/wooorm/test/blob/main/directory/example.md` or `/directory/example.md`.
 if (value.charAt(0) === slash) {
 if (!config.urlConfig.hostname) {
 return
 }

- // Create a URL.
- value = https + slashes + config.urlConfig.hostname + value
+ // A root absolute path without the repo, "blob", and branch name: `/directory/example.md`.
+ // TODO: Figure out how this applies, if at all, to GitLab and Bitbucket.
+ if (!config.urlConfig.prefix.startsWith(value) && config.urlConfig.hostname === 'github.com') {
+ const valueRelativeToRoot = value.slice(1)
+ value = path.resolve(config.root, valueRelativeToRoot)
+ } else {
+ // Create a URL.
+ value = https + slashes + config.urlConfig.hostname + value
+ }
 }

 /** @type {URL|undefined} */

If that's ok I'll open a PR.

Just discovered that this is missing! I thought it was working until I renamed the file that was referenced by relative-to-repo-root syntax. Looking forward to a fix.

Is it possible to get this merged? This would be really useful for my project (it's not really checking links that use absolute paths from the repo root) when running `remark`.


Question: throughput of the stream is too low?

We're currently not using batched writes, so it's not unexpected that you can't fill a 10 Gbit link.

There's been work on using the `sendmmsg` API in URL which surfaced that we were allocating like crazy, which was killing performance due to GC constantly kicking in. In the mean time, we've done a lot of work to reduce allocs, and we'll be done >80% once we merge all the outstanding PRs linked in URL
There's also some subtle issues with how Go delivers packets from the kernel to the QUIC layer, which affect how timely we can acknowledge incoming packets, which has complicated implications on the congestion controller.

Other than that, there's a new Go API in the works to allow batched writes in a more efficient way: URL I expect huge performance improvements from this, but obviously we'll have to wait for this API to actually be implemented before we can put numbers on this.

throughput of the stream is too low
Hello, I'm testing the throughput of the quic stream on the localhost.

In my test, I can only obtain a throughput of approximately 5MBps.

Test environments:
 quic-go version: 0.51.0, 0.48.0, and the perf tool
 OS: window11 or ubuntu2204
 go version: go1.23

The results of throughput tests obtained on these platforms are roughly the same, all very low. I want to know what might be the reason for this?

Thank you!

The following is my test code:

// client
data := make([]byte, 8192)
for i := 0; i < 8192; i++ {
 data[i] = byte(i)
}
cnt := 100000

stream, err := conn.OpenStreamSync(context.Background())
if err != nil {
 return err
}
defer stream.Close()

for i := 0; i < cnt; i++ {
 _, err = stream.Write(data)
 if err != nil {
 return err
 }
}

// server
conn, err := listener.Accept(context.Background())
if err != nil {
 return err
}

var totalBytes int64
var started bool
var startTime time.Time

stream, err := conn.AcceptStream(context.Background())
if err != nil {
 log.Printf("AcceptStream error: %v", err)
}
defer stream.Close()

buf := make([]byte, 8192)
for {
 n, err := stream.Read(buf)
 if err != nil {
 if err != io.EOF {
 log.Printf("Stream %d error: %v", stream.StreamID(), err)
 }
 break
 }
 if !started {
 started = true
 startTime = time.Now()
 }
 totalBytes += int64(n)
 elapsed := time.Since(startTime).Seconds()
 currentBandwidth := float64(totalBytes) / (elapsed * 1e6)
 fmt.Printf("\rCurrent throughput: %.2f MBps", currentBandwidth)
}
return nil

I also conducted tests on up to 32 streams, and the obtained throughput was approximately the same.

It's not very helpful to open an issue saying "things are slow". For some definition of "slow". Slow? Slow compared to what?

Things you could look into: flow control (and the respective tuning parameters) and congestion control.

Sorry for not describing the problem clearly.

I saw that in the descriptions of some previous issues (#3670), the throughput they tested could reach 1100Mbps, while my test results were far lower than this value. I want to know what the maximum throughput that quic-go can achieve is without changing any code. I think a throughput of 5MBps is obviously unreasonable.

I tried to increase the congestion window and the flow control window, but there was no obvious change in throughput.

How?

The specific value will obviously depend on your benchmarking setup. For example, if you're still in the early phases of slow start, throughput might still be slow. If you're blocked by flow control, things might be slow. If you're running on localhost, things might be slow due to oscillating RTTs. Lots of potential culprits...

Oh, I found that printing logs has a significant impact on throughput. When I turned off log output, the throughput reached 500MBps!

Thank you for your reply!

Oh wow, that's a lot!

Just out of curiosity, were you printing logs using `QUIC_GO_LOG_LEVEL=debug`, or were you using qlog?

Throughput of quic-go
Hi community,

I am testing the maximum achievable throughput of quic-go and for this purpose I've modified the `echo.go` example to read a large file (>15GB) and send it to a server. The client and server are running on two different hosts (Ubuntu 22) with a unused 10Gigabit link between them. I am achieving a maximum throughput of ca. 1100 Mbit/s. Would be this number expect by anyone else or should quic-go actually be able to achieve more? I'm open to feedback to improve my example so that we can see a better throughput.
Thanks in advance.

I haven't looked at the echo code, but you might be limited by this single payload scenario. In a more request-heavy scenario I've been able to push 10-15 Gbits from a single host quite easily (even with some added complexity, not just copying bytes back and forth) and I believe I've seen people do even more (check past issues here).

@kokes Thank you for your reply, would you share with me your example where you were able to push that big amount of Gbit per second? Sounds very interesting to me and would be very handful proof of quic-go for my thesis. Thanks in advance.

It's a pretty complex codebase, so I can't quite extract the logic into a minimal example. But simply open up multiple streams and push (smaller) payloads through them. You should see much higher aggregate tput then.

Looking at the echo example - you'll need to dispatch the handlers in the server part (right now it sequentially processes the first stream on one connection at a time), that should be just a goroutine with some coordination. And same on the client side - launch multiple requests through new bidirectional streams.

I'm not a big expert in Go, could you give me a hint how many streams should I open?

I tried with multiple streams(up to 32) by sending smaller files (200MB and 2GB) and I get almost always a throughput around 1100Mbit/s.

Just a hint. Running into a bottleneck due to encryption is a real concern at 10G. You need to make sure, that you can encrypt traffic at a rate of at least 10G.

We performed similar tests in a 10G network years ago, probably even on the same Network. If I could remember correctly, we archived thru-puts of around 350 Mbit/s. We linked the limit to a bottleneck in the encryption/decryption of the network traffic. Enabling AES-NI in Bios resulted in a real improvement. After enabling it, we archived thru-puts similar to yours.

This is quite important.

Single stream HTTP/1.1 with TLS 1.2/1.3 (AESGCM128 afaik), can do about 360MB/s (3600Mbps) on a single core (no ktls). C (openssl, wget, curl), Go (`net/http`), Python (`requests`) all show me about 350MB/s one way over single stream (Python about 220MB/s). I was not able to reach 25Gbps, not even close.

In theory QUIC maybe could do even better by exploiting more CPU parallelism. But very fat streams are a bit niche. Still, QUIC should not regress compared to HTTP/1.1 with TLS 1.3.

AMD Threadripper 2950X, Zen+, 3.2GHz. So a bit dated.

quic-go now enables GSO by default. This should bring down CPU load quite a bit, and improve throughput on connections that were previously CPU-limited.


Question: Parsing error: Cannot use keyword 'await' outside an async function?

I can try to roll one later, but if there’s no _need_ for you to run with a newer version of `eslint-plugin-n` then you can simply downgrade it to the version that `standard` expects.

Parsing error: Cannot use keyword 'await' outside an async function
**What version of this package are you using?**

14.3.4

**What operating system, Node.js, and npm version?**

Node: 14.13.0
npm: 6.14.8
OS: macOS Catalina 10.15.5

**What happened?**

Given code:

js
import { fileURLToPath } from 'url'
import fs from 'fs'
const file = await fs.promise.readFile(fileURLToPath(import.meta.url))
console.log(file.toString())

Output is:

standard: Use JavaScript Standard Style ( URL
 example.mjs:3:14: Parsing error: Cannot use keyword 'await' outside an async function

**What did you expect to happen?**

`Top-level await` is a stage 3 proposal (see URL but is enabled by default in from Node 14.8.0 (see URL

This is going to mean that linting with apps written for Node 14+ will be problematic, as top-level await is bound to be used.

Since Node 14 is becoming Active LTS in a few weeks I think TLA should pass linting

**Are you willing to submit a pull request to fix this bug?**

yes

With AWS Lambda now supporting top level await ( URL I imagine a lot more will run into this parsing error. It looks like `eslint@8` ( URL has been released.

@willfarrell you can follow Standard 17 (which uses ESLint 8) progress here: URL

Prerelease `17.0.0-0` of `standard` is now released, containing ESLint 8 support, which should fix this issue. See: URL

Would love if you could all test this and report back here if this is still an issue 🙏 We'll reopen this if its still an issue.

@voxpelli Something wrong is not right

js
// main.js
await new Promise(resolve => resolve())

sh
Sandbox $ standard --version
17.0.0-0
Sandbox $ standard .\main.js
standard: Use JavaScript Standard Style ( URL
 .\Sandbox\main.js:1:1: Parsing error: Cannot use keyword 'await' outside an async function (null)

Furthermore, VSCode (`standard.vscode-standard v2.0.1`) don't show Standard errors anymore.

@NemoStein Right, thanks, I'll reopen. Have you tested in plain ESLint 8 and seen if it works there? Maybe we need to explicitly allow it?

In regards to the VSCode extension, that one needs an update, I highlighted that in URL now 🙏

just had a quick look and standard 17 doesn't support class instance fields, either (which eslint 8 does)

js
class Test {
 something = 1
}

export default Test

$ standard instance-field.js
standard: Use JavaScript Standard Style ( URL
 /Users/lloyd/Documents/instance-field:2:13: Parsing error: Unexpected token = (null)

@voxpelli Ok, here goes my 2 cents.
Using only ESLint, if you don't set the `parserOptions.ecmaVersion` to `"latest"` it also triggers the error

js
// .eslintrc.js

module.exports = {
 env: {
 es2021: true,
 },
 parserOptions: {
 ecmaVersion: 'latest', // resolve())

With `parserOptions.ecmaVersion: "latest"`

sh
$ eslint .\main.js
$

Without

sh
$ eslint .\main.js

.\main.js
 1:1 error Parsing error: Cannot use keyword 'await' outside an async function

✖ 1 problem (1 error, 0 warnings)

$

@NemoStein Yeah, I arrived at the same conclusion, will merge and release URL when another maintainer gives me a review 👍

@NemoStein @75lb We just released `17.0.0-1` with a fix for this. Unless URL overrides that fix, then it should work now, else we'll try to get a fix in for that issue and releases a `17.0.0-2` tomorrow. Both me and @Divlo needs some sleep now 😅

Sadly it does, but I can confirm that updating the `eslint-config-standard-jsx/eslintrc.json` to `"ecmaVersion": 2022` works.

`17.0.0-2` should finally be fixing this + we now have tests that ensures that ensures that's the case

Ship final version of `17.0.0`
Me and @Divlo shipped `17.0.0-0` today, #203, following the merge of #193.

`17.0.0-0` is a _prerelease_.

One can install it using `eslint-config-standard@next`

Being a pre-release, `17.0.0-0` comes with no guarantees in regards to support / breaking changes etc. It exists to facilitate early feedback, from the wider community as well from our selves.

Next steps before we will ship a stable release of `17.0.0` are:

* [x] Merge new `standard-engine` into `standard`: URL
* [x] Ship a new major of `eslint-config-standard-jsx`
* [x] Update `standard` to `17.0.0-0` of this module + the new major of `eslint-config-standard-jsx`
* [x] Ship a `17.0.0-0` of `standard` to start getting some feedback on ecosystem compatibility
* [x] When we're confident that the ecosystem is ready for a stable `17.0.0`, roll one for this module...
 * [x] Ship a `17.x` compliant update to `vscode-standard` ( URL
 * [x] All of the external tests in `standard` passes ( URL
 * [x] `standard-engine` generated types ( URL + CI succeeds
* [x] ...and then a stable `11.0.0` of `eslint-config-standard-jsx`
* [x] ~~...and then a stable `12.0.0` of `eslint-config-standard-react`~~ **Not used, skipped**
* [x] ...and then a stable `15.0.0` of `standard-engine`
* [ ] ...and then a stable `17.0.0` of `standard`...
* [ ] ...and then new version of the long tail of `standard`-siblings, like `semistandard`...
* [ ] ...then close this issue and the `17.0.0` milestone

In the meanwhile, please report any breakage you discover 🙏

Prerelease `17.0.0-0` of `standard` is now released: URL

We will be checking the stability of this ourselves, but would love for as many of our users to test it out as well and report back to us whether it's time to party or time to head back into the workshop and reshape things. Thanks 🙏

Any update on the final 17? Working with it since 3 weeks, looking good to me...

@feross
understand that there are many moving parts here before full release

could 'latest' tag, at least, be bumped to pick up dep change @

 URL

? it's currently causing breakage, e.g. in VSCode's Redhat Dependency Analytics / snyk usage.

@pgnd What breakage is caused where?

The `latest` tag will and should always be pointing to the newest stable release.

@Divlo We can release a stable before @feross chimes in, since its just a dependency update. We still have URL to fix though

@voxpelli understood. if i can get RH tool working in my env, I'll readd it and get the details to you. Atm, it's a 'doorstop'.

yarn add --dev eslint-config-standard@next

installs 17.0.0-1, from Jan 31 tag

which does NOT yet contain the relevant fix from

 URL

a pre-release 17.0.0-2 tag could allow building transient dependencies that rely on eslint-config-n@latest without getting npm errors, that's all. We build an in-house eslint library for vue-cli5, and as of right now we have a breakage because of conflicting versions ubtil 17.0.0 i s released or a new beta tag is posted. If possible, we'd like to not do yet another fork of an eslint-related project 😅

Ping :) I always need to manually handle the result of npm outdated for this repo. Any chance to get that done?
grafik

@JanFellner Feel free to help going through URL :) That's the main blocker.

We won't release this as stable without having passing integration tests for the wider community as failures there can just as much mean that we had unintended rule changes in the ESLint 8 move as it can mean that the external projects have gone bad themselves.

Also: If you know of large projects using this that aren't present in the external tests there, then please make an issue or PR there to suggest adding them. The more insight we can get into community breakage / support, the more confident we can become in shipping things quickly.

(Right now I myself am pretty busy with my paid job, so haven't had time to look at the mentioned issues in a while)

looking, the aparently still open issues are

 LAST COMMIT
 _____________
 URL 2022-03-17
 URL 2022-03-30
 URL 2021-05-07
 URL 2020-10-29
 URL 2022-03-16
 URL 2020-10-29
 URL 2022-02-27
 URL 2021-08-01

Some are recently active, some, clearly ... aren't.

iiuc, no eslint8-ready `eslint-config-standard` v17x final release until each/all of those are updated?

@pgnd

I don't think strictly that we should fix all the `test-external` before releasing v17, even if it would be better for sure, I don't think this is necessary as most of the failing ones are unmaintained repo with no activity recently, and also most of the repo in `test-external` still use `var` keyword to declare variables (they are mostly old codebases)...

I think it would be worth disabling some of them (see this file: URL
Also, we might consider doing a major "refactoring" for this, and only do `test-external` for a repo that at least use v16 of `standard` and that is actively maintained (I know actively might be subjective but I think we should define what is "active" and we can pretty much agree that repo with no commits since 3 years is unmaintained), I saw some of them still using `standard` v14.

I agree, this also seems to be the backwards way of doing this, it's after all a major upgrade, so maybe there should be a PR for those projects to ease their upgrade, but if that PR is discarded or the project is not even using an up to date version of standard or their is no activity on the project they should definitely not block the upgrade in itself. I know some projects will be reluctant to change from var to const because they want to keep backward compatibility with the super old nodejs versions, and well we can't blame them for not wanting to release a major over code style

Adoption won't happen until it is fully released, and those forgotten projects will either update in their own time or get forked into oblivion

@voxpelli whats your thinking about removing outdated packages as mentioned by @Divlo and @Tofandel.
This currently seems to block the final shipment of v17?

I'm 👍 on that, though I want to go through them to see if the failures are because of an unintended change or because of eg. lack of maintenance on their path.

I'll try to find time soon to look at what eg. @Tofandel summarised here. Main blocker from my side has been my time 🙈