Jshint: إعادة تعريف الوعد (W079)

حسنًا ، هذا لأن Promise أصبح عالميًا مضمّنًا الآن. هذه نقطة جيدة نحتاج إلى إصلاحها بطريقة ما. بمناسبة P1.

أيضًا ، لا يمكنني رؤية كيف يمكنني إيقاف تشغيل Promise كعالمية مضمنة. لقد حاولت تعيين browser: false لكنه لا يزال يعتبر عالميًا.

+1 أستخدم browser: false و node: true . كنت تعتقد أن هذا سيعمل ، ما لم يكن لدى Node خطط لإضافة Promise عند ترقية V8.

وعود gabegorelick موجودة بالفعل في العقدة غير مستقرة لذا أنا متأكد من أنها ستكون في العقدة V0.12 ، إذا أطلقوها بالفعل ...
أعتقد أننا ربما نريد علامة أكثر وضوحًا ثم node أو browser للسماح بإعادة التعريف هذه للسماح بفترة تكيف للوعود الأصلية.

عثرة على هذا. تلقي نفس الأخطاء.

هل تكتب هذا؟

var Array = require("my-array-implementation");

... أو تمهيد أي كائن مدمج آخر؟

نقطة ممتازة. هل تقترح استخدام بعض البدائل إذن ، مثل BluebirdPromise ؟ أنا منفتح عليها ، فقط أحببت المقروئية وأنا تعريف. لا تريد أن تمهد أي شيء.

بالتأكيد ، أو BPromise أو أي شيء آخر ، شيء لا يتعارض مع التعليمات البرمجية الأخرى التي قد تتوقع أن يكون Promise على ما هو عليه. الحقيقة: أراد المجتمع أن يلتزم الوعد باللغة وهذا ما حدث. أحد الآثار الجانبية هو أن كلمة "وعد" لم تعد متاحة للجميع بعد الآن.

rwaldron أنا أتفق معك بالفعل. سأعيد تسمية مراجعي فقط.

مكالمة جيدة @ rwaldron ، أوافق.

رائعة! هذا قرار تقدمي للغاية: د

بدلاً من إعادة تسمية المراجع الخاصة بي ، وجدت حلاً مختلفًا:
لقد قمت للتو بإضافة ما يلي إلى ملف .jshintrc الخاص بي

"globals"      : {
    "Promise"   : true
}

يعمل بشكل جيد !
تحرير: لأكون واضحًا ، لا أعتقد أن هذا حل جيد جدًا ، إنه فقط الأسهل بالنسبة لي الآن. يبدو أن استخدام مرجع بديل مثل BPromise هو الحل الأفضل بالنسبة لي.
لن أستخدم Bluebird كمرجع كما فعلوا هنا: https://github.com/krakenjs/kraken-js/commit/701f4c34753e53cec24da84ac9bf658243e83e6c يبدو الأمر محرجًا بالنسبة لي ، يجب أن يكون واضحًا أنه وعد بغض النظر عن التنفيذ.

rwaldron لا أوافق مع the community wanted الوعد baked into the language لكونه سببًا لجعل Promise اسمًا عالميًا لأن اللغة الآن! = بيئة Node.js! = بيئة المتصفح. لا ينبغي أن يكون jshint مقيدًا جدًا في هذه الحالة ، أود أيضًا أن أقول إنه تغيير غير متوافق مع الإصدارات السابقة والذي أدى إلى تحديث الإصدار الثانوي الذي بدأ يؤثر على جميع إصداراتنا (وربما الأشخاص الآخرين). لا أعتقد أنك ستجادل في أن الكثير من المطورين يستخدمون bluebird ويقومون بتعيينه إلى Promise ولا أعتقد أننا سنرى أصلي Promise in Node.js قريبًا بما يكفي للمطالبة بـ Promise كشركة عالمية في كل مكان. حتى عندما يكون لدينا Promise في كل مكان ، سيكون من الصعب التبديل من bluebird أو أي مكتبة يستخدمها الأشخاص لأنهم يستخدمون أيضًا واجهات برمجة تطبيقات إضافية توفرها تلك المكتبات. الحل مع globals: { ... } هو أيضًا فكرة سيئة لأنك تقدم نقطة ساخنة وإذا نسيت أن تفعل var Promise = ... ، jshint لن تشكو ، لكن الكود الخاص بك سوف تتعطل أثناء وقت التشغيل. سيكون اقتراحي إما التأكد من أن Promise ليس عالميًا افتراضيًا عند node: true أو التراجع عن التغيير بالكامل والسماح للأشخاص باتخاذ القرار حتى نرى Promise ممكّنًا افتراضيًا (w / o أعلام إضافية أو سحر ، وما إلى ذلك) في Node.js والمتصفح.

Promise هو بالفعل عالمي في V8 / عقدة طالما قمت بتمرير --harmony-promises أو --harmony .

في V8 3.28.71.2 ، يتم تمكين مجموعات الوعد والرمز والتناغم (Map / Set / WeakMap / WeakSet) افتراضيًا (مع مصفوفات الانسجام وعدد قليل من الميزات الأخرى التي ستظهر قريبًا) ، لذا فهي مسألة وقت فقط قبل ذلك. يتم تمكين هذه بشكل افتراضي ما لم تحذف joyent / strongloop تلك الكرة الأرضية بشكل صريح أثناء bootstrapping ، وهو أمر يبدو غير مرجح.

يعد Promise جزءًا من النظام البيئي ، ولكن من المنطقي أن تكون قادرًا على تعطيل es6 globals في التكوين ، IMO. (إذا كنت تريد معرفة كيفية ظهور الميزات الأخرى ، فإن http://www.chromestatus.com/features#es6 هو مؤشر جيد على وقت وصوله إلى V8 ومتى يتم تشغيله بشكل افتراضي).

لما يستحق الأمر ، فإن Mozilla لا تخفي حتى ميزات التناغم وراء التفضيل ، ويتم تمكين عدد من هذه الميزات افتراضيًا في Chrome --- لذا فهذه بيئة browser . بالنسبة للعقدة ، كما قيل أعلاه ، إنها حقًا مسألة وقت

caitp ليس في العقدة v0.10.x و v0.12.x لم يتم إصدارهما بعد (وربما لن يتم إصداره للأشهر N القادمة) وحتى عندما يأتي إلى هذا العالم ، أشك في أن الناس سيذهبون إلى قم بالتبديل على الفور وأشك أكثر في أن الناس سوف يعملون في الإنتاج --harmony-promises . أوافق على أنه يجب أن يكون هناك نوع من خيار es6 في التكوين. سيكون انتصارًا للجميع.

يوجد خيار es6 ، ولكن لم يتم تحديد الكرات العالمية الوعد والرمز والانعكاس والخريطة والمجموعة و WeakMap و WeakSet مسبقًا بناءً على وجود هذا العلم.

ربما يجب أن يكونوا كذلك ، ربما يكون من السهل جدًا وضع CL معًا

xaka لقد أضفت جميع أسماء api العالمية الجديدة إلى قائمة معرفات Ecma ولن أخرجها. اعتبارًا من 2.5.4 ، يمكنك القيام بذلك:

/* global -Promise */
var Promise = require("promise");

أو في predef في a .jshintrc:

{
  "undef": true,
  "unused": true,
  "predef": [ "-Promise" ]
}

هل هناك أي سبب لعدم نجاح ما يلي على مستوى الوحدة النمطية؟

var Promise = global.Promise  || require("promise");

أو هذا على المستوى العالمي

var Promise = Promise  || require("promise");

سيؤدي ذلك إلى تحرير الوحدة من المخاوف التي لا ينبغي أن تكون بها ، ولكن في أي حال إذا تم كسر التطبيق الأصلي فعليًا ، لا أفهم سبب عدم قدرتنا على الكتابة فوقه محليًا أو حتى عالميًا ، كما حدث من قبل لإصلاح المحركات هنا و هناك.

أتساءل لماذا تم إلقاء التحذير أيضًا على نطاق الحظر:

const Promise = require('bluebird');  // same for `let`

لن يتم المساس بالمتغير العام في هذه الحالة.

إذا كان بإمكانك استخدام ميزات ES6 (العقدة 0.11+) وتم إصلاح # 2090 ، فلن تكون إعادة تسمية المتغير ضرورية بعد الآن.

لن يتم المساس بالمتغير العام في هذه الحالة.

هذا صحيح ، ويجب تقديمه كمسألة مختلفة - وهذا ما فعلته ، شكرًا!

ولكن...

إذا كان بإمكانك استخدام ميزات ES6 (العقدة 0.11+) وتم إصلاح # 2090 ، فلن تكون إعادة تسمية المتغير ضرورية بعد الآن.

let و const في الإصدار 8 (كما هو موضح في العقدة 0.11.x) هي تطبيق نموذج أولي لم يعد صحيحًا (كما هو الحال في عدة سنوات قديمة) وبالتالي _ ليس _ ميزة ES6 ، لذلك يجب ألا تستخدمها حقًا ، لأنها لا تلتزم بدلالات المواصفات.

لذلك يجب ألا تستخدمها حقًا ، لأنها لا تلتزم بدلالات المواصفات.

في الواقع ، من فضلك ، من فضلك لا تستخدم هذه (في أي من العقدة أو في تطبيقات الويب) --- وإلا فإننا قد لا نكون قادرين على شحن السلوك "الصحيح" ؛ _؛ وسيكون ذلك محزنًا. إذا رأيت سلوك let / const قديمًا في البرية ، فيرجى إخبار الأشخاص المناسبين لإزالته

تضمين التغريدة

هل يمكن لأي شخص الرجوع إلى معلومات حول ما تغير حول const و let ؟
لم أتمكن من العثور على أي معلومات حول ذلك ولا أرى أي سبب لعدم استخدامه في Node.

fluidsonic يبدو أن إصدار v8 الذي يعمل في العقدة 0.10.35 يحتوي على دلالات TDZ ، ولكن لا يزال Let and const مقصورًا عن قصد (وبشكل غير صحيح) على رمز الوضع الصارم.

أهلا جميعا،

يتضمن JSHint 2.8.1 ( تم إصداره اليوم ) خيارًا جديدًا باسم futurehostile والذي صممناه ليكون بديلاً أكثر قابلية للفهم لـ predef: ['-Promise'] . امل ان يساعد!

^ _2.6.1_

لا أعرف كيف يمكن فهم ذلك بشكل أكبر ، لكن على أي حال ... ؛)

حتى مع وجود Promise في الإصدار 8 / io.js ، بطيئته المميتة ، و _ على عكس _ Array ، تم تصميم Promise بشكل صريح للسماح بالتطبيقات البديلة والقابلة للتشغيل البيني.

Promise = require('bluebird');

يجب أن يكون تحذيرًا

var Promise = require('bluebird');

لا ينبغي أن يكون ، IMO. لقد ذهبت إلى طريق الكرة الأرضية ، ماكينة الصراف الآلي.

@ دومينيك - أحب مدخلاتك هنا. هل تجاوز window.Promise على الويب أو global.Promise على العقدة / ioj ضمن النطاق المحلي دليل على المستقبل؟

مثال:

var Promise = require('bluebird');

هل تجاوز النافذة الوعد على الويب أو الوعد العام. الوعد على العقدة / iojs ضمن النطاق المحلي دليل على المستقبل؟

هذا متناقض مع الذات.

لا ، إنه مستقبل عدائي.

@ دومينيك - شكرا!

rwaldron -

هذا متناقض مع الذات.

اسف لخلط الامور. لقد قمت بتحديث سؤالي للتوضيح. قصدت ، "يتم إعادة تعريف Promise المدمج في نطاق محلي مقاوم للمستقبل".

الأمثلة التي قدمها petkaantonov في بلوبيرد تعيد تعريف Promise المدمج ، مما دفعني للتساؤل عما إذا كانت هذه ممارسة مقبولة بالفعل (في حالة Promises على وجه الخصوص - وفقًا لتعليق @ sam-github).

يبدو أن الجواب "لا".

https://github.com/jshint/jshint/issues/1747#issuecomment -94024023

@ دومينيك لماذا المستقبل معادية؟ تم تصميم الوعود صراحةً من قبل المواصفات لدعم عمليات التنفيذ المشتركة البديلة ... لماذا لا تستدعي تنفيذ الوعد المستخدم في وحدة عقدة معينة Promise ، بدلاً من ، على سبيل المثال ، Bluebird ، أو MyPromise ؟

هل سيؤدي هذا إلى إرباك محسن الإصدار 8 بطريقة ما؟ لا أعتقد ذلك.

أم لأنك تأمل أن تموت جميع عمليات تنفيذ الوعد الأخرى ولن يبقى سوى الشحن الوحيد في وقت تشغيل js؟

للسبب نفسه ، يعد الكتابة فوق Object أو Map أو window أمرًا عدائيًا في المستقبل.

لا أدري. يبدو أن var Promise = Promise || require('bluebird') دليل مستقبلي ، وليس عدائيًا في المستقبل. الكائن موجود دائمًا ، الوعد بالكاد موجود.

التعامل معها على أنها قابلة للتبديل طريقة جيدة لاختراق الويب ، من فضلك لا تفعل ذلك باستخدام أحدهما أو الآخر ، بشكل صريح

للسبب نفسه ، يعد الكتابة فوق كائن أو خريطة أو نافذة عدائية في المستقبل.

نعم ، تمامًا كما قلت من قبل.

آه ، حسنًا ، هذا يدور فقط في دوائر ، ولكن أي محاولة جادة لإقناع العالم بأن جميع الكودات الموجودة التي تحتوي على var Promise أصبحت فجأة خاطئة في وقت ما مؤخرًا (حتى في البيئات التي _ ليس لديها وعد _ تنفيذ ، مثل جميلة كل كود العقدة في الإنتاج) ، سيستغرق المزيد من العمل.

رسم التشابهات بين أنواع Promise و js المضمنة التي كانت موجودة منذ عقود يحتاج إلى نسخة احتياطية أكثر قليلاً من مجرد التأكيد على أنها متشابهة.

(حتى في البيئات التي لا يوجد بها تنفيذ الوعد ، مثل جميع رموز العقدة تقريبًا في الإنتاج)

لا توجد طريقة لـ JSHint لمعرفة وقت تشغيل الكود الذي يقوم بتحليله. لن يقوم JSHint بكسر كود الإنتاج لأي شخص. إذا كنت ترغب في تمهيد روابط Identifer للكائنات المضمنة ، فقط قم بذلك ، وأخبر JSHint أن يصمت

فقط قم بذلك ، وأخبر JSHint أن يصمت

هذا جيد تمامًا - لكن حاول ألا تعامل عمليات التنفيذ الأصلية وتطبيقات الطرف الثالث على أنها قابلة للتبادل ، إلا إذا كان لديك سبب وجيه للتأكد من أن تطبيق الطرف الثالث متوافق مع المواصفات قدر الإمكان ، أو يحاول على الأقل أن يكون ، بحيث يكون هناك مجال أكبر قليلاً لتوسيع المواصفات إذا احتاجت إلى ذلك دون تعطل التطبيقات

var Promise = Promise || require('bluebird')

هذا مروع ، لا تفعل ذلك أبدًا

كيف يجب إصلاح هذه المشكلة في النهاية؟

لقد جربت

futurehostile : true,

لكن لا يزال لديك هذا التحذير:

من جهة أخرى:

predef   : ['angular','-Promise']

يعمل ، ولكن كما أفهم ، يجب أن ألتزم بالحل الأول.

أي أفكار؟

لدي مشكلة مماثلة:
لدي ملف أستخدمه في كل من المتصفح والعقدة ؛
عندما أكون في المتصفح ، أعتمد على الوظيفة باعتبارها وظيفة عامة (إنها كائن يحتوي على مجموعة من المطابقات المخصصة لياسمين) ، ولكن عندما تكون في عقدة ، أقوم بتصديرها عبر module.exports.

"use strict";
var module = module || {
    exports : {}
};

function Matchers(){ 
    // code...
}
// code...

module.exports = Matchers;

Jshint يرمي الخطأ:

  line 3  col 5  Redefinition of 'module'.

سؤالين:

1. إذا كان ما أفعله على ما يرام ، فهل هذا خطأ في jshint؟
2. إذا لم أفعل هذا ، فماذا أفعل؟

@ andrew-luhring بجانب الكتلة الفارغة داخل المُنشئ ، سيمر هذا:

"use strict";
var module;
if (!module) {
    module = {
        exports: {}
    };
}

function Matchers() {
    // put something here
}

module.exports = Matchers;

ماهو الفرق؟ في الواقع ، لا يوجد فرق ملموس مع ما كتبته ، إنها مجرد إطالة أكثر وربما طريقة واضحة لفعل الشيء نفسه (كنت سأستخدم نسختك أيضًا ، أعط JSHint دورة ؛-))

هتافات

ربما أفتقد شيئًا ما ، ولكن هل هناك طريقة لمنع هذا الخطأ؟ أنا أستخدم esnext: true ، وهو الخيار الذي يولد الخطأ ، وقد جربت مثل هذه الخيارات المتنوعة لتجاوز سلوك الوعد المحدد مثل

  "globals": {
    "Promise": false // or true
  },
  "-Promise": false,
  "predef": [ "-Promise" ]

ولكن لا يبدو أن أيًا منهم يتجاوز الخطأ.

الخطأ يحدث فقط مع let Promise = و const Promise= . لا يوجد خطأ في var Promise=

تحديث : بعد بعض العقود الآجلة ، حصلت عليها للعمل معها
"globals": { "Promise": null }

مرحبًاjoegoldbeck. بينما أنا سعيد لأنك وجدت حلاً لحل مشكلتك
المشكلة ، هذا ليس استخدامًا معتمدًا رسميًا لتكوين globals .
نظرًا لأننا لا نوثقها أو نختبرها ، فقد لا تعمل في إصدار مستقبلي من
JSHint. لقد تحققت للتو من أن التكوين التالي يمنع التحذير
لقد أبلغت عن ارتباطات let و const :

{
  "esversion": 6,
  "predef": ["-Promise"]
}

هذا نهج أكثر أمانًا ، لذا يرجى استخدامه بدلاً من ذلك.

مرحبا jugglinmike شكرا على الرد! أنا أفضل استخدام التكوين المدعوم. الشخص الذي تقترحه لا يعمل معي لسبب ما. لقد جردت .jshintrc الخاص بي بحيث يحتوي فقط على تلك الأسطر وما زلت أتلقى تحذير W079. أنا أستخدم JSHint v2.9.4 في WebStorm.

أود أن أشير إلى أنه حتى يومنا هذا ، اعتبارًا من أبريل 2017 ، لا تزال مستندات Bluebird توصي بهذا الاستخدام في Node:

var Promise = require("bluebird");

وكل جزء من التوثيق يستخدم أسماء مثل Promise.promisifyAll (وليس Bluebird.promisifyAll ) لوصف الأساليب المتوفرة في Bluebird ولكن ليس في Promise الأصلي.

لهذا السبب أتوقع من الجميع اتباع الاستخدام الموصى به في وثائق Bluebird ما لم يتغير ليعكس التوصية الواردة هنا.

انظر: http://bluebirdjs.com/docs/getting-started.html

أيضًا ، يبدو أن Bluebird لا توافق على أن إعادة تعريف Promise فكرة سيئة - راجع قضية petkaantonov / bluebird # 715 - لذا يبدو أن اتباع أمثلة Bluebird ستؤدي إلى كسر الشفرة باستخدام ESLint. يبدو أنه لا يوجد إجماع هنا.