ما هو السلوك المتوقع؟
يجب ألا يشتمل مشروع pdfjs-dist على حزمة الويب باعتبارها اعتمادًا على نظير peerDependency لأنها يمكن أن تعمل حقًا بدونها عند تحميل البرامج النصية من دليل الإنشاء.
ماذا حصل؟
أنا أستخدم PDFJS في أحد المكونات لتصور ملف PDF باستخدام Angular 6. لا يتضمن حزمة الويب في مشروعي (لست بحاجة إليها على الإطلاق) ، قم بعمل نافذة منبثقة لتحذير peerDependency في كل مرة أقوم فيها بتشغيل أي أمر npm أو في كل مرة يقوم أي شخص بتثبيت المكون الخاص بي .
بالضبط. وجود webpack
كـ "peerDependency"
في حزمة قابلة للتوزيع مثل هذا أمر خاطئ تمامًا ويجب إزالته.
تمت إضافة تبعية الأقران في # 9249 بسبب worker-loader
. هل يمكنك توضيح سبب الخطأ في وجوده في مستودعنا؟ أنا بخير مع إزالته إذا كان من المؤكد أنه لن يكسر الأشياء.
مرحبًا ،timvandermeij. شكرا لردك!
webpack
هي أداة بناء ، وعلى هذا النحو ، فهي عادة ما تكون منطقية فقط مثل "devDependency"
- أو أنها مقتصرة على مسار بناء المكتبة. يعني تضمينه كـ "peerDependency"
أن المستخدمين يحتاجون إما إلى تثبيته محليًا (على الرغم من أنهم قد لا يحتاجون إليه / لا يهتمون به) أو تجاهل التحذير الذي ينبثق في كل مرة على npm install
.
لست على دراية بـ worker-loader
، لذا خذ تعليقاتي بقليل من الملح. ولكن إذا كان مثل أي أداة تحميل أخرى webpack
، فعادة ما تكون مطلوبة فقط كخطوة تكوين بناء ولا شيء آخر. أيضًا ، لا يكون ذلك منطقيًا في سياق حيث من المفترض أن تُستخدم المكتبة خارج الويب (مثل Node).
هل يعمل pdf.js
كمكوِّن إضافي من نوع webpack
في بعض الحالات؟ إذا كان _is_ ، فمن المنطقي تضمين كل من المُحمل و webpack
كتبعية. ولكن ، حتى ذلك الحين ، كنت أزعم أنه يجب استخراج هذا النوع من الدعم إلى الريبو / الوحدة النمطية الخاصة به.
لقد أخذت حريتي في تزييف الريبو وأخذ كل شيء يتعلق بـ webpack
. لا يزال يعمل بشكل جيد بالنسبة لي في تطبيق Node الخاص بي.
هل هناك أي خطة لإزالة حزمة الويب باعتبارها تبعية. nfantone هل كنت تخطط لتقديم العلاقات العامة؟
mishawakerman لم webpack
على أنه تبعية. يخبرني حدسي (المحدود) أن هذا جزء من مشكلة أكبر حيث يقترن pdf.js
بجزء من تنفيذه الذي يعتمد بشكل غير مباشر على webpack
ويحتاج إلى إعادة تشكيله بطريقة ما.
تم طرح هذا السؤال أيضًا على IRC وحصلنا على هذه الإجابة: https://mozilla.logbot.info/pdfjs/20180606#c14862530 -c14862541. باختصار ، أنا لست على دراية حقيقية بتجميع Webpack نفسه ، ولكن إذا كان حقًا يتعلق فقط بالمثال الذي أعتقد أنه يمكننا إزالته. يرجى التحقق مما إذا كان هذا هو الحال قبل تقديم PR بالرغم من ذلك.
الإغلاق لأن القيام بذلك ليس خيارًا جيدًا حقًا نظرًا لأن # 9248 سيعود إذا فعلنا ذلك. بدلاً من ذلك ، ما يجب أن نفعله هو # 9580 الذي تمت مناقشته في IRC على https://mozilla.logbot.info/pdfjs/20180606#c14862530 -c14862634.
التعليق الأكثر فائدة
مرحبًا ،timvandermeij. شكرا لردك!
webpack
هي أداة بناء ، وعلى هذا النحو ، فهي عادة ما تكون منطقية فقط مثل"devDependency"
- أو أنها مقتصرة على مسار بناء المكتبة. يعني تضمينه كـ"peerDependency"
أن المستخدمين يحتاجون إما إلى تثبيته محليًا (على الرغم من أنهم قد لا يحتاجون إليه / لا يهتمون به) أو تجاهل التحذير الذي ينبثق في كل مرة علىnpm install
.لست على دراية بـ
worker-loader
، لذا خذ تعليقاتي بقليل من الملح. ولكن إذا كان مثل أي أداة تحميل أخرىwebpack
، فعادة ما تكون مطلوبة فقط كخطوة تكوين بناء ولا شيء آخر. أيضًا ، لا يكون ذلك منطقيًا في سياق حيث من المفترض أن تُستخدم المكتبة خارج الويب (مثل Node).هل يعمل
pdf.js
كمكوِّن إضافي من نوعwebpack
في بعض الحالات؟ إذا كان _is_ ، فمن المنطقي تضمين كل من المُحمل وwebpack
كتبعية. ولكن ، حتى ذلك الحين ، كنت أزعم أنه يجب استخراج هذا النوع من الدعم إلى الريبو / الوحدة النمطية الخاصة به.لقد أخذت حريتي في تزييف الريبو وأخذ كل شيء يتعلق بـ
webpack
. لا يزال يعمل بشكل جيد بالنسبة لي في تطبيق Node الخاص بي.